A customer needs to submit a request or view their own job information. That is a different requirement from publishing a brochure website or giving staff an internal app. Start with what the visitor must be able to do.
A Dark Cloud Creative provides Perth based scoping and remote help across Australia. Implementation responsibilities and fees are agreed once the access and data requirements are clear.
Decide whether a portal is needed
A public information page may only need a conventional website. A visitor who must sign in and reach business records introduces a broader application requirement. We establish that distinction before recommending Power Pages.
Use one visitor journey to explain the task. Include what they submit, what they can see and how staff respond.
Review the records behind the website
Power Pages works with business data stored in Microsoft Dataverse. The environment and records need to support the intended process. A portal should not become a separate place to maintain conflicting copies.
We identify data ownership and the fields visitors need. Any required integration or migration belongs in the scope before pages are built.
Define authentication and record access
A signed in customer should only reach the information intended for them. Public forms, authenticated pages and administrator functions require different access decisions. The design must account for the underlying data permissions.
Agree on user roles and account recovery. Relevant tests should include attempts to reach another customer’s records as well as ordinary successful use.
Check capacity and subscription dependencies
Power Pages has its own licensing and capacity considerations. User audiences, environments and connected features affect the operating arrangement. An existing Microsoft 365 subscription is not proof that a portal is covered.
We document assumptions and required subscriptions in the feasibility review. The business should understand ongoing costs before accepting a development proposal.
Test the complete visitor task
A working sign in page does not prove the visitor can submit a request, correct an error or find the result. Test normal use and relevant failures with appropriate accounts and sample data.
Larger portal builds can be scoped with VibeZero where appropriate. The acceptance brief should explain the expected result and each provider’s responsibilities.
Plan updates and support after launch
The handover needs to identify the environment, domain and operational owner. Include access changes, support contacts and how faults are reported. Content editing and data administration may have different responsibilities.
Any ongoing arrangement should state its coverage and availability. A launch does not imply unlimited development or continuous incident monitoring.
