When hiring a Microsoft Power Pages developer for a client onboarding portal, look beyond whether they can create pages and forms. The project may also require external-user authentication, Dataverse data modeling, organization-specific permissions, SharePoint document handling, Power Automate workflows, integration testing, deployment, and documentation.
A good selection process asks candidates to explain how they would solve the business workflow, protect each client's data, handle failure cases, and deliver a maintainable solution in the organization's environment. Request evidence of relevant experience, but do not rely on a technology list alone.
1. Verify external-facing portal experience
Power Pages work for internal users is not identical to a portal used by external clients. Ask candidates to explain their experience with external authentication, portal roles, table permissions, record relationships, document access, and testing unauthorized access.
Useful questions include:
- How do you prevent one client organization from accessing another organization's records?
- How do you test permissions beyond the normal user interface?
- How are client contacts related to organizations and onboarding cases?
- How do you handle access revocation?
- How do you protect uploaded documents and direct file links?
Ask for a walkthrough or sanitized example that does not expose another client's confidential information.
2. Check the complete workflow skill set
Depending on scope, the project may require experience across:
- Power Pages for the external portal.
- Dataverse for data modeling and permissions.
- Power Automate for reminders, notifications, and workflow routing.
- SharePoint Online for document storage and staff collaboration.
- Power Apps for internal review and case management.
- APIs and connectors for existing business systems.
- Environment management, deployment, testing, and documentation.
The strongest fit is not necessarily the person who lists the most tools. It is the person who can explain why each component is needed, what alternatives exist, and how the complete workflow will be supported.
3. Ask for a clear architecture and data model
Before committing to the full build, ask the developer or agency to explain:
- The main records and their relationships.
- How organizations, contacts, onboarding cases, tasks, and documents relate.
- Which system owns each data item.
- How external and internal permissions differ.
- What triggers each automated action.
- How integration errors are handled.
- How development and production environments will be managed.
The client onboarding portal architecture guide provides a useful starting point for these discussions.
4. Make security testing a deliverable
Do not accept "the portal has login" as proof that client data is protected. The scope should include explicit tests for unauthorized access to records and documents, attempts to modify identifiers, restricted updates, and access changes after a user is removed.
Ask for a test plan with expected outcomes and evidence. See how to keep each client's data separate in Power Pages.
5. Clarify project scope and acceptance criteria
A proposal should specify deliverables, assumptions, exclusions, dependencies, milestones, and acceptance criteria. For example, the definition of done might require:
- External users can sign in through the agreed authentication approach.
- Users see only records they are authorized to access.
- Required forms and document submissions work end to end.
- Staff can review submissions and request corrections.
- Status tracking and agreed notifications work.
- Error and security test cases pass.
- The solution is deployed into the designated company-owned environment.
- Documentation and handoff are completed.
The exact acceptance criteria must be agreed for the project; this list is an example, not a guarantee of scope or effort.
6. Discuss licensing and ownership early
Clarify who owns the Microsoft tenant, environments, data, source assets, connections, service accounts, and deployment process. Confirm that the organization - not an individual contractor's personal environment - will control the production solution as agreed.
Ask the candidate to identify the licensing assumptions that need verification. Microsoft licensing depends on the actual user model, components, capacity, and current terms. It should not be left as an unexamined assumption in the proposal.
7. Evaluate communication and long-term support
A portal often evolves after launch. Assess whether the developer can explain trade-offs clearly, document decisions, manage change requests, diagnose failures, and hand over the solution to internal staff or another provider.
Agree on how issues will be reported, what maintenance is included, how enhancements are estimated, and who is responsible for monitoring flows and integrations.
8. Compare candidates consistently
Use the same questions and scoring criteria for each candidate.
Do not score a candidate solely on the lowest initial price. A credible proposal should expose assumptions and risks instead of hiding them.
Prepare a brief before requesting proposals
Use the client portal requirements checklist to document user types, forms, documents, statuses, notifications, integrations, security, and acceptance criteria. The cost guide can help you understand the main effort and licensing drivers.
Xcesslogic can discuss the workflow and help determine the scope, technology choices, and implementation approach for a client portal project.
