Skip to main content

Submissions

1. Overview​

1.1 Introduction​

This section explains the end-to-end component submission workflow for Financial Institution (FI) users within the Developer Console.

The Developer Console provides a structured and secure platform that enables FI users to:

  • Create and manage their own dedicated private GitHub repository.
  • Submit components (currently Aspects, with widget support planned in future releases).
  • Track the complete lifecycle of submissions, including validation, review, and deployment.
  • Engineering and security teams reviewal through GitHub PR workflows.
  • Publish validated components to the Staging Experience Group.
  • Deploy published components to the Production Experience Group.
  • Manage collaborators and access controls securely.

2. Login and Default Admin Setup​

2.1 New FI – Admin Behavior​

When a new FI is onboarded:

  • A default Admin user is created by the Candescent onboarding team.
  • Only users with Admin and Developer roles can access the Submissions tab.
  • Spectators cannot view or access the Submissions tab.

3. First-Time Setup – Build Component (New FI Only)​

3.1 Build Component​

To build a new component, follow the steps:

  1. Click the Submissions tab from the left navigation pane.

Build-Component

  1. Click Build Component.

Build-Component-Button

When clicked:

  • The user receives an email to Accept Invitation for the GitHub repository.
  • Access is granted after accepting the invitation.

4. Component Submission Form (UI Flow)​

After clicking Build Component, the user is navigated to the Component Submission Form.

4.1 Submission Form Capabilities​

  1. Select Platform
    • Web
    • Mobile
  2. Provide Code

    • Enter either JavaScript code directly in a textbox

      OR

    • Select an existing GitHub PR dropdown (if already created)

  3. Select Component Type
    • Dropdown selection (e.g., Aspect)
  4. Provide Metadata
    • Component name
    • Description

4.2 Action Buttons​

  1. Cancel
  • Displays the Are you sure you want to submit your component for review? dialog.
  • Redirects user back to Submission Dashboard.
  • No submission is created.
  1. Submit for Approval
  • System validates all required fields.
  • PR is created and linked to metadata.
  • User is redirected to Submission Dashboard.
  • Newly submitted component appears in the list.

5. Submission Dashboard​

After submission (or for already onboarded FIs), users will see the Submission Dashboard.

5.1 Dashboard Features​

  • View all submissions.
  • Search by component name.
  • Filter by:
    • Status
    • Timeline
  • Click on a submission to view details.

Submission-Dashboard

5.2 Component Details View​

The following timeline structure(s) are displayed:

StageDescription
In ReviewSubmission created. Security scans are in progress, and the submission is under review.
Engineering ValidationCode is being reviewed by the engineering team.
Security AssessmentSecurity validations are in progress or completed.
Published to StageComponent successfully published to the staging environment.
Deployed to ProductionComponent successfully deployed to the production environment.

You can also:

  • View GitHub reviewer comments within the UI.
  • Click Read More to navigate to GitHub.
  • Click GitHub links to open the PR(s) directly.

6. Environment Isolation & Deployment​

6.1 Default Behavior​

  • All submissions are published to the Staging Experience Group by default.
  • When a user submits a component through the Developer Console, it is not directly deployed to Production.
  • Instead, after successful validations and approvals, the component is first published to the Staging Experience Group.

This ensures:

  • Safe testing and validation before production rollout.
  • Reduced risk of introducing issues into the production environment.
Important Notes

Staging acts as a pre-production environment where users can verify functionality before deployment.

6.2 Deployment Actions​

Once a component reaches the Published status, it becomes eligible for deployment to Production.

  • A Deploy button is displayed for each eligible submission in the dashboard.
  • The button is enabled when the status is Published or if there is a failure while publishing to the Staging Experience Group.
  • For all other statuses, the Deploy button remains disabled.

Once Deploy is clicked:

  • The system initiates the deployment process.
  • The component is moved from Staging to Production Experience Group.
  • The deployment is completed as part of the same action.
  • The Deploy button is removed after deployment to production, indicating that the process is complete.
Important Notes

Deployment marks the final step in the submission lifecycle and makes the component live in the production environment of the experience group.

6.3 Access of Staging Experience Group​

  • Access to the Staging Experience Group is managed separately by the DSM (Delivery/Support Management) team.
  • The Developer Console does not manage or grant access permissions to Staging Experience group.

If a user does not have access:

  • They may not be able to view or validate the component in Staging.
  • Once the status is Published, users can deploy the component to the Production Experience Group using the Deploy button on the dashboard.
Important Notes

Users should coordinate with their DSM team to request access to the Staging environment if required.

7. Role-Based Access in Developer Portal & Repository Permissions​

7.1 Roles with access to the Submissions tab:​

RoleAccess
AdminFull access
DeveloperSubmit and view
SpectatorNo access

7.2 GitHub Team Requirements​

Even if a user is an Admin or Developer of the Developer Portal:

  • They must be part of the FI GitHub team.
  • If not part of the GitHub team:
    • They can only view the dashboard.
    • The New Submission button is disabled.
    • They cannot view PR details or create submissions.

7.3 Restrictions​

  • Users cannot access other FI repositories.
  • Each user has access only to their own FI private repository.

8. Manage Collaborators​

Only Admin users can manage collaborators (i.e., add and remove collaborators).

8.1 Admin Capabilities​

In the Manage Collaborator tab:

Admins can:

  • Add users by entering email address.
  • Remove collaborators
  • View details:
    • FI ID
    • FI Name
    • GitHub Repo URL
    • Action column

8.2 Developer Restrictions​

  • Developers cannot add or remove collaborators.
  • The Manage button is disabled for developers.

8.3 Adding a Collaborator​

When an Admin adds a user:

  1. The user must already exist in User Management (with an Admin or Developer role).
  2. The user receives a GitHub invitation email.
  3. After accepting the invitation, the user gains access to the FI private repository.

9. PR Workflows & Approvals​

9.1 Workflow Stages​

Once a submission is created, the workflow stages are:

StageDescription
ReviewPR created, scanning initiated, or updated with reviewer comments.
RevisionsChanges requested by reviewers; update the PR and resubmit.
ApprovedAll scans passed and approvals from Engineering and Security completed.
PublishedAspect successfully published to the Staging Experience Group.
DeployedAspect successfully deployed to the Production Experience Group.
FailedSubmission failed due to scanning or publishing issues.
ClosedPR closed without merging; submission no longer active.

9.2 User Capabilities During Review​

  • Users can edit the code in the GitHub PR.
  • Users can merge the PR only after obtaining engineering and security team approvals.
  • Users cannot assign reviewers.

10. Email Notifications​

Users receive email notifications for:

  • PR creation
  • Security scanning results
  • Engineering validation updates
  • Security assessment updates
  • Reviewer comments
  • Approvals
  • Merging PR

11. Publishing & Deployment Flow to Experience Group​

Once a component is:

  • Approved by engineering team
  • Approved by security team

Then:

  • The user can publish the component or merge the PR.
  • The component is listed in the Staging Experience Group of the Admin Portal.
  • The status updates to Published.
  • Once the component is in Published status, the user can trigger deployment using the Deploy button to deploy the component to the production experience group.

12. Already Onboarded FI Scenario​

If the FI is already onboarded and has submitted a component before:

  • After login, the user can view the Submission Dashboard.
  • All submissions for the FI (across users) are made visible.

13. Security & Isolation​

  • Each FI has a dedicated private repository.
  • No cross-FI visibility.
  • Role-based UI restrictions are enforced.

14. Troubleshooting Submission Failures​

If a submission fails, check the GitHub Action logs for the specific cause of the failure. The logs will indicate whether the issue is a configuration error, a validation failure, or an Aspect limit violation.

14.1 Aspect Limits​

Each Experience Group has a defined limit on the number of Aspects it can contain. If a submission fails due to a limit violation:

Remove an existing Aspect that is no longer needed. Re-run the GitHub Action job. To increase your Aspect allocation, contact your DSM.

15. Additional Support​

For questions or issues related to the Submission Portal, contact [email protected].

Next Steps​

To search and discover details around Marketplace Products, visit Marketplace Product Catalog.