A client onboarding process is difficult to manage when staff have to open emails, check shared folders, and update spreadsheets to determine what remains outstanding. A structured onboarding tracker can show the current stage, required actions, responsible owner, and items blocking completion. Power Apps and Dataverse can support an internal tracking experience, while Power Pages can present the appropriate status to external clients.
The important first step is to define what "progress" means for the business. A status label alone is not enough: the system needs clear completion criteria, task ownership, and rules for handling incomplete or rejected submissions.
Define stages and completion rules
A simple workflow might use these stages:
- Draft: The onboarding case exists but has not been submitted.
- Submitted: The client has sent the initial information.
- Under Review: Staff are reviewing the submission.
- Action Required: The client or staff member must resolve an outstanding item.
- Approved: Required information has passed review.
- Complete: All required steps and approvals are finished.
These are illustrative labels. Use terms that match the organization's actual process. Define whether a case can move backward, who can make each transition, and whether some steps can happen in parallel.
Do not automatically mark a case complete simply because a form was submitted. Completion might require several accepted documents, an internal approval, a successful integration, or another business condition.
Model the information needed for tracking
A useful tracker may need:
- Client organization and contact.
- Onboarding case identifier and creation date.
- Current stage and submission date.
- Required documents and their review status.
- Outstanding tasks and their owners.
- Last activity and next action.
- Due date or escalation state where applicable.
- Completion date and relevant audit history.
Keep the model proportionate. Avoid creating fields that nobody uses or maintaining the same status independently in several places. Determine which records are authoritative and how status is updated.
Design two views: client and staff
The client view should be simple and action-oriented. It may show the current stage, submitted items, missing requirements, and the next step. It should not expose internal notes, staff-only review details, or other clients' information.
The internal staff view can provide more operational detail, such as assigned reviewer, age of the case, outstanding tasks, exceptions, and filters for cases requiring attention. Access should be based on staff responsibilities and permissions.
The client-facing view can be part of Power Pages, while an internal Power Apps interface may be useful for review and case management. Choose the least complex supported design that satisfies the actual workflow.
Build useful reporting, not vanity dashboards
Managers often need answers to practical questions:
- How many cases are awaiting client action?
- How many are waiting for internal review?
- Which cases have remained in one stage longer than expected?
- Which document requirements cause the most delays?
- How many cases were completed during a defined period?
- Where are handoffs or integrations failing?
Agree on metric definitions before reporting. For example, "time to complete" needs a defined start event, end event, and treatment of paused cases. Otherwise, different reports may produce misleading comparisons.
A dashboard should help someone decide what action to take. If a chart does not influence a decision, it may not belong in the first release.
Keep progress synchronized with workflow events
Progress indicators should update when meaningful events occur: a client submits a form, a document is accepted, staff request a correction, or an approval is completed. Power Automate can coordinate notifications and process transitions where appropriate.
See automating client onboarding with Power Automate. For document-specific states, read how to collect client documents online using Power Pages and SharePoint.
Test unusual paths
Include cases such as:
- A client submits only part of the required information.
- A document is rejected and replaced.
- A reviewer is reassigned.
- A case is cancelled or reopened.
- Several tasks are completed in a different order.
- An integration fails after the client submits information.
- A user loses access while the case is still active.
Define what the client sees and what staff can do in each scenario. This prevents the tracker from displaying a reassuring "complete" status when work remains outstanding.
Start with operational visibility
A useful first release may need only a clear case list, defined statuses, outstanding-item indicators, and notifications. Add performance dashboards after the organization has reliable data and knows which questions the reports need to answer.
For the full design, see the client onboarding portal guide. The requirements checklist helps define stages, ownership, and reporting before implementation.
