Best practices and considerations for Onboarding essentials (preview) design

  • Article

Onboarding Essentials offers a range of customizable components designed to cater to various onboarding scenarios. You have the flexibility to build an application by blending the Onboarding components with the platform's prebuilt elements. Onboarding essentials can support multiple business scenarios.

The Onboarding Essentials Solution Architecture article explains the architecture of the building block. This article guides you through the practical applications of the Onboarding Essentials toolkit components to enhance an Onboarding application within the realm of financial services. By following these suggestions, you can embrace a configuration-first approach and harness the toolkit's existing features to their fullest potential. Further, you can uncover opportunities for tailoring aspects such as the business process flow, application queue, task management, task progress tracking, declared assets and liabilities, declared income and expenses, customer snapshot, and integration to cater to unique extension requirements.

Overview

Consider deploying the Loan onboarding application as a sample to demonstrate the functionality of the Onboarding Essentials toolkit. (If you prefer not to incorporate Loan Onboarding into your primary implementation, you can deploy it in a dedicated sandbox environment solely for experimentation purposes.) The following diagram shows the Loan onboarding sample application's architecture:

A diagram showing the solution components of loan onboarding sample application

Download a printable PDF of this diagram.

The Loan Onboarding sample application features a data model extension that includes tables related to loans, such as Loan Applications, Loan Application Collateral, Collateral, and Loan Application Collateral Valuation. You can deploy sample data related to loan applications, considering that you can't remove the data after deploying it from the Solution Center.

The sample data encompasses various configurations, including task definitions, related party roles, application categories, and more. On the automation side, the Loan Onboarding solution incorporates a Loan-specific Business Process Flow and defines a cloud flow responsible for populating the application queue. Additionally, other cloud flows generate document requests, such as income statements for primary parties and identification document requests for related parties. The identification document type uses document intelligence capabilities to verify and extract information. The cloud flows cover the identification document pipeline, verification, and enrichment steps.

The Loan onboarding model-driven application streamlines the process for loan officers. The application uses the Onboarding essentials components, such as customer snapshot, assets and liabilities, income and expenses, application queue, task manager, application progress, and documents. The model-driven application also incorporates platform components to capture additional parties, application information, and activities. Furthermore, the application ribbon is customized to prominently display key actions for loan officers, including the creation of new loans or the archival of existing ones.

The following diagram illustrates these Onboarding essentials extension areas for the implementors with the use of built-in controls, configurations, and automation of Onboarding essentials and the customization capabilities of Power Platform.

A diagram showing the Onboarding essentials extension areas

Download a printable PDF of this diagram.

This article explores the extension scenarios listed here and presents you with an approach for their implementation. Further, it explains the considerations and best practices to consider when designing these scenarios:

  1. Add new onboarding application scenario
  2. Add task definitions
  3. Add task generation
  4. Add an application queue
  5. Add document definitions and document requests generation
  6. Set up your onboarding application
  7. Cancel an existing task

Scenario-1: Add new onboarding application scenario

Scenario-1: Requirement

Empowering the capability to introduce a new business scenario to accommodate a fresh onboarding application, like Loan or Account onboarding.

Scenario-1: Approach

You can set up multiple business scenarios using the Onboarding essentials toolkit. Each scenario has its own model-driven app created to set up your Onboarding application. The model-driven application always uses the Application table as all connection is already in place with it. As you want to support multiple scenarios, you might have to add more details to the Application table. The recommended way is to place the business data of each business scenario on a different extended entity. In the Loan onboarding sample application, the data model is extended with tables such as Loan Applications, Loan Application Collateral, Collateral, and Loan Application Collateral Valuation.

Similarly, for example, if you have an Account onboarding scenario, you can create an Account application table to store the relevant data and connect it with application using polymorphic lookup to the Details field. (You can use the Dataverse API or XRMToolbox community tool to add the relationship to existing polymorphic lookup fields.) In subsequent sections, you can see how to add your relevant business scenario table and connect either with the application or with the related party.

A diagram showing how to add your business scenario relevant table and connect either with the application or with the related party.

The application form guides the Onboarding agent through the process, while tasks direct the agent to specific tabs. To display relevant information, define forms and views for the sub-grid. Utilize the Details polymorphic lookup to include detailed information from connected tables such as Loan Application or Account Application.

Scenario-1: Considerations and best practices

Enhance the data model to include all the required business data

  • If you need to extend the data model for the specific scenario with a one-to-many relation, consider to connect them with the Application table and not only with the scenario specific table. This way, you can add information using a sub-grid directly on the Application form. For example, Loan application is the newly created table that supports the Loan onboarding process. Further, you need to add collaterals to the loan applications. If you add the one-to-many connection to the Application table, you can add the loan-related information and the collaterals on the Application form:

A screenshot showing how to enhance the data model to include all the required business data extending the application form.

  • Related party can hold all necessary information from the applicants. However, in some cases, the onboarding scenario is relevant for existing customers. Here, you can use the Party polymorphic lookup to connect the Contact (in retail or wealth scenario) or Account tables (in the SME scenario) with Related Party. As a result, you can efficiently transfer all existing relevant information using either a built-in workflow or a Power Automate flow. (Copying the current data is valuable for financial institutions to track information that might change over time, such as addresses.)

Define the application categories

  • The Business Scenario category can be utilized to determine whether a task is relevant to a specific category. (For example, if you have an Account onboarding scenario where you have tasks that are relevant only for joint accounts and not for a sole account, you can create a category for a sole account and another one for a joint account.) One task definition can support a single business scenario and multiple categories. If you've already defined tasks, ensure that you include the newly created category in the appropriate task definitions.

  • Application categories records are solution-aware. We recommend shipping these definitions as part of your custom solution.

Define the onboarding applicant roles

  • The onboarding applicant roles can be utilized to determine whether a task is relevant to a specific role/party. If you've already defined tasks, ensure that you include the newly created role in the appropriate task definitions (where association type is role).
  • Related Party roles records are solution-aware. We recommend shipping these definitions as part of your custom solution.

Create a scenario-specific Business process flow (BPF) and connect it with the business scenario

  • Only one BPF can be assigned to a business scenario and a model-driven application.
  • A BPF must be defined to incorporate the Application Queue and Application Task Manager components.
  • BPF stages are used to specify relevant tasks for each stage.

Customize and create business scenario-specific forms and views

  • Each Onboarding application has specific details. To provide the Onboarding agent with the relevant scenario information, you need to create a specific Application form for each scenario.
  • Tasks can direct the Onboarding agent to specific tabs. When you design a new Application form, consider creating tabs for specific tasks. Ensure that you name all added tabs and make notes for reference when configuring task navigation.
  • Make sure you add the OnboardingEssentialsFormOnLoad JavaScript to your Onboarding application form, and add onboardingEssentials.formOnLoad function, and select the Pass execution context as first parameter.

A diagram showing how to add the OnboardingEssentialsFormOnLoad JavaScript to your Onboarding application form

  • When you design the application creation process, it's important to consider whether this system serves as the primary platform for application creation. If it's the master system for creating applications, you should create a dedicated form specifically for application creation. This form should include only the essential fields required for adding a new application. Make sure to include the Business Scenario and Application Category fields on the creation form and mark them as required. These fields play a vital role in task generation and queue management. Additionally, ensure that users can't update these fields later, as allowing updates can lead to inconsistencies in task and queue management.

Scenario-2: Add task definition

Scenario-2: Requirement

Ability to generate tasks specific to a business scenario and specify their relevance to a particular application category or related party role.

Scenario-2 Approach

You can create task groups and task definitions for the task generation workflow to create the tasks when an application or a related party is created. Furthermore, task navigation can direct the Onboarding agent from the Application Task Manager to the appropriate tab.

Scenario-2: Considerations and best practices

  • To create the task groups and task definitions, you need to define the business scenario, extend the data model, and add application categories and related party roles as prerequisites.
  • Task group, Task definition and Task navigation records are solution-aware. We recommend shipping these definitions as part of your custom solution.
  • If you use the Document intelligence control, consider creating a task definition for reviewing the documents. After the Onboarding agent successfully verifies all the documents, they should update the status of the Review documents task to Done.
  • You can use the Process stage attribute to link tasks to the corresponding business process stage. As a result, the Onboarding agent can determine which tasks to prioritize during the current stage of the application.
  • If the association type is Role, ensure that you add the relevant party roles to the sub-grid after you create the task definition. If you don't specify the related party roles, the flow doesn't generate the tasks.
  • If you define a task with the trigger type Complex, ensure that you create a Power Automate flow to generate the task.
  • If the task type is Verification, ensure that you create a task navigation that guides the Onboarding agent to the linked tab. Use the type General if there's no associated tab.
  • Ensure that you include the application categories after creating the task definitions. If you don't add the appropriate application categories, the flow doesn't generate the tasks.

Scenario-3: Add task generation

Scenario-3: Requirement

Generate the defined application and role level tasks when you create a new application.

Scenario-3: Approach

On the task definition, you can define the trigger type as standard or complex. Task creation for Application and Task creation for Related party cloud flows are part of the Onboarding Essentials Tasks solution. These two flows generate the relevant business scenario tasks when the application is created or a new related party is added. Both flows filter the task definitions based on the Application type and Trigger type columns. If you need a specific logic or additional steps, you can set the trigger type to Complex and create your own Power Automate flow. See Define task workflows.

Scenario-3: Considerations and best practices

  • The task modification process isn't automatically triggered when you modify the applicant role or define a new primary applicant. You need to handle the process manually.
  • If the standard task workflows need to be changed, consider to turn them off, make a copy of them and make the necessary modifications on the copied flows and then turn them on.
  • Consider deleting tasks for archived applications if the customer doesn't track or audit them after archiving.

Scenario-4: Add an application queue

Scenario-4: Requirement

Enhance Onboarding agent efficiency by managing applications in a queue specific to a business scenario and grouping them by stages.

Scenario-4: Approach

The application queue component is based on the platform's core queue capabilities.

  • Create a Queue for your onboarding applications - To learn more about queue capabilities, see Queue entities.
  • Add Queue item table to your solution and create a new view for it.
  • Add custom control properties to your newly created view
  • Define the application queue attributes to display

Scenario-4: Considerations and best practices

  • Adding an application queue isn't mandatory. This component is meant to help Onboarding agents to prioritize their work. You can use standard views as well.
  • Business scenario settings should define the business scenario for the model-driven application to set up the application queue properly. If the settings are missing, the application queue doesn't show the applications, and instead, shows an error message.
  • Onboarding scenario definition is a prerequisite for the application queue in order to group the applications by the business process flow stages.
  • One model-driven application can handle one business scenario and one business process flow.
  • Create a Power Automate flow to add newly created applications to the related queue.
  • You must create a specific view for each business scenario. For example, the sample application has an Account application view for the Account business scenario. If you configure multiple scenarios, the view must filter only the relevant business scenario. For more information, go to Set up multiple business scenarios.
  • Queue actions such as Pick and Release aren't supported in the current release.
  • You can deploy Loan onboarding sample application (to a sandbox environment) to examine through a well-architected example how application queue can be added to your model-driven application.

Scenario-5: Add document definitions and document requests generation

Scenario-5: Requirement

Ability to define relevant documents that need to be uploaded and reviewed during the application process. Enhance Onboarding agent efficiency by defining the necessary documents for upload and review during the application process, while harnessing AI capabilities for document verification and data extraction.

Scenario-5: Approach

You have to add document definitions that are relevant to your business scenario. You can refer to Configure a document definitions and design best practices for Document Intelligence.

Suppose you want to generate document requests on creating an application or a related party. In that case, you need to create a Power Automate flow, which creates the document requests based on the document definitions. (For example, you can deploy and observe how Loan Onboarding generates Identification and Income Statement requests.)

Scenario-5: Considerations and best practices

  • If you use the Document intelligence control, consider to create a task definition to review the documents. Set up the task navigation in order to navigate directly to the Document tab. After the Onboarding agent successfully verifies all the documents, they should update the status of the Review documents task to Done.
  • You can use the new approach to define a solution-aware long-term data retention rule (preview) for notes entity or use the legacy approach to define bulk-deletion job to remove old documents.

Scenario-6: Set up your Onboarding application

Scenario-6: Requirement

Ability to create a purpose built business scenario specific Onboarding application.

Scenario-6: Approach

Each business scenario must have its own model driven application. To create your Onboarding app you can use the Onboarding essentials toolkit components, combined with the platform capabilities, and also you can extend with your own custom-developed components. (For example, you can develop your own PCF control, embed Power Apps Canvas app, or embed Power BI tiles and dashboards)

  • In your unmanaged solution, create a new Model-driven application.
  • Add Application table to your solution (if you haven't already added it) and create a new form specific to your new business scenario.
  • Add Queue Item to your Navigation (Sitemap) and change the title to reflect your business scenario (for example, Loan applications).

A sample screenshot showing how to add the navigation sitemap.

  • Select your Business Process Flow that is specific for your business scenario.

A sample showing how to extend your business process flow.

  • Make sure you enable only the necessary view(s) for the Queue item . If you use the Application queue, then you need to enable the view you created with the custom control.
  • Add components to the Application for and configure them. The following components are optional and you can add them based on the business requirements.
  • Add Customer snapshot control to the form to show the most relevant information about the Primary party.
  • Add the additional applicants (Related parties) sub-grid to the form if in your business scenario multiple applicants can be added to one application. (For example: Co-borrower)
  • Embed the Application task progress overview control to give an overview of the application's status.
  • Set up Application task manager and content tabs. You can add additional tabs with your relevant forms and set up the navigation from a task to a specific tab.
  • Add the Declared assets and liabilities control if it's relevant in your scenario.
  • Add the Declared income and expenses control if it's relevant in your scenario.
  • Add the Document intelligence control if you have document management requirements in your scenario.
  • Add additional Power Apps components and fields, like timeline control. Embed your custom PCF control or Power BI tiles, dashboards.
  • Add Business scenario settings value

Settings help to provide customized app experience. They define the business scenario for an application. The application queue uses this value to use the relevant business process flow stages for the queue. Add Business scenario settings to your solution.

A diagram showing how to add Business scenario settings to your solution
A diagram showing how to add setting definition to your solution

Select the Business scenario settings and add a new app value. Use the Business scenario choice value you've created.


A diagram showing how to add a new app value to scenario settings

  • Create security roles for your model-driven app based on entity mapping

Scenario-6: Considerations and best practices

  • If you want to use a different form to create a new application, you can modify the new button on the ribbon to define which form you want to use for creation.
  • Business scenario settings should define the business scenario for the model-driven application to set up the application queue properly. If the settings are missing, the application queue doesn't show the applications, and instead, shows an error message.
  • You can copy the Onboarding agent security role and extend it for your business scenario. We recommend a dedicated security role for each onboarding scenario.
  • If you want to add assets, liabilities, income and expenses, ensure that you define the relevant Onboarding financial types. The specified components are solution-aware and we recommend shipping the definitions as part of your custom solution.
  • If you use Declared assets and liabilities or Declared income and expenses component, you need to create new forms for the Related party table, where you can use these controls. Assets, liabilities, income, and expenses are connected to the Related party table.
  • You can deploy Loan onboarding sample application (to a sandbox environment) to examine through a well-architected example of a model-driven application.
  • Business scenario and application category are tightly connected with task management and queue management. You need to hide or set those fields to read-only, as Power Automate flows aren't triggered for those modifications.
  • On the Related party form, consider hiding the Role field or making it read-only after creating the related party, as the field defines the generated tasks and document requests.
  • In the model-driven application settings, enable only the forms and views that are specific to your business scenario so that users can't make any accidental changes.

Scenario-7: Cancel an existing task

Scenario-7: Requirement

Ability to cancel an existing task and set up how ongoing applications should handle the cancellation.

Scenario-7: Approach

You can cancel a task and prevent new applications or related parties from generating that task. Use the Cancel task configuration to define how the cancellation affects ongoing applications. See Cancel task definition for details.

Scenario-7: Considerations and best practices

  • For existing workflows, you must either populate the Attribute status and Status reason values in the Cancel tasks configuration table for the workflow to work properly or leave the table empty.
  • The Cancel task display environmental variable defines whether you can see the canceled tasks in all the Onboarding applications. The variable isn't specific to any business scenario or application.

See also

Next steps