Customer and account operations
How customer applications become live customers and, when requested, accounts.
remoteEaze uses a Customer Application as the normal Dashboard journey for creating a customer. The application selects the governing onboarding and KYC policies, collects the required information, follows an assigned workflow, and produces the live Customer record when the configured approval path completes.
Do not treat Create a customer and Onboard a customer as separate normal Dashboard journeys. The customer is created from the completed application.
The onboarding journey
- Start a customer application and create its Draft record.
- Complete customer data, KYC, and requirements at the stages where the workflow requests them.
- Assign, review, and progress the application through its configured paths.
- Approve the application and create the customer. An optional Account request can run after Customer creation.
These pages describe the Dashboard journey under Customer Relationship → Applications. For offline capture, see Workbench customer onboarding.
Access is permission-based
Customer Application does not use the generic maker-checker approval sequence. Access instead depends on the user's Customer Application permissions, data-access scope, the current application state, an accepted workflow assignment, and the workflow's authorized stages, transitions, requirements, and actions.
| Permission | What it allows |
|---|---|
| Read Customer Application | Open the Applications list and application details within scope. |
| Create Customer Application | Start an application in an allowed company and branch. |
| Update Customer Application | Correct eligible application fields and capture customer, KYC, and requirement data. |
| Assign Customer Application | Assign, reassign, self-assign, or accept current-stage work. |
| Process Workflow | Record ordinary decisions, evaluate KYC, advance an allowed transition, retry an eligible Account post-action, and complete manual Customer creation where the runtime permits it. |
| Waive Customer Application | Record an exception only where the policy or requirement is configured as waivable; a reason is required. |
Having a permission does not guarantee that every corresponding button appears. The current stage, assignment, action configuration, application status, and record scope must also allow the operation. See Roles and permissions and Data-access scope.
Application and KYC status are separate
The application header shows both Application and KYC status. A Submitted or In Review application can still have pending KYC work. Approval requires KYC to be Passed or validly Waived, together with all other blocking controls.
Common application outcomes are Returned for Correction, Approved, Rejected, Closed, Withdrawn, and Customer Created. The configured workflow transition determines the outcome; these are not L1, L2, or L3 maker-checker states.