Getting started with Full Service
Thank you for choosing Power Portals Pro Full Service. Your subscription includes 20 hours of initial setup and configuration. The more of the following you can gather before our kickoff call, the more of those hours go into building your portal rather than collecting information.
You don't need every answer before we start. “Not sure yet” is a fine answer, and we'll work through it together.
1. People
- A project lead: the person who makes decisions about the portal and signs off on go-live.
- A Dataverse System Administrator for a short one-time setup call. It involves creating application users for our applications (see section 3) and assigning their security roles.
- A Global Administrator for your Microsoft tenant, to approve our applications (see section 3). Their part is a single approval for each.
- Who to contact about billing and technical matters, if these are different people.
2. Your Dataverse environment
- The address of the environment the portal will connect to, for example
https://yourcompany.crm.dynamics.com. - Whether you'd like changes tried somewhere first, such as a sandbox environment, before they reach your live data.
3. How we connect to your Dataverse
We connect to your Dataverse through two applications, each as a dedicated application user rather than as one of your staff:
- The portal itself connects as the App User, with a purpose-built security role that covers only what the portal needs.
- We set up and maintain the portal through Power Portals Pro - Deployment Admin: installing and upgrading our managed solution, and making the security changes your portal needs. It needs the System Administrator role.
The Deployment Admin
Your Global Administrator approves our “Power Portals Pro - Deployment Admin” application once, and your System Administrator creates an application user for it and assigns it the System Administrator role.
- It signs in with a certificate held in Azure Key Vault, which can't be copied out of it, so there is no password that could leak.
- You stay in control. You can disable its application user at any time; the running portal is unaffected, but we can't make changes until it is enabled again.
The App User: whose app registration?
The App User is tied to a Microsoft Entra app registration, and you choose who owns it.
Option A: we use our app registration (recommended)
Your Global Administrator approves our “Power Portals Pro - App User” application once.
- Pros:
- Nothing for you to create or maintain.
- It has no secret at all: the portal proves it is our application with an Azure managed identity that exists only on our hosting, so nothing expires and there is nothing to leak or rotate.
- It is the quickest way to get started: a single approval.
- It requests only the basic sign-in-and-read-profile permission that Microsoft requires to approve any app, and the portal doesn't use even that.
- Cons:
- It needs a Global Administrator's approval of an application from outside your organization, which some security policies don't allow.
Option B: you use your own app registration
Your administrator creates an app registration in your tenant and shares its secret with us securely.
- Pros:
- You own it outright and can rotate or delete it whenever you like.
- It suits organizations whose policies don't allow outside applications.
- Cons:
- Your administrator creates and configures it.
- Its secret expires (the Microsoft Entra admin center allows at most 24 months). Before it does, your administrator has to create a new one and send it to us. If it lapses, the portal stops working until it is replaced.
Under either option, disabling the application user in your Dataverse environment cuts off the portal's access immediately.
4. Your web address
- Do you want the portal on your own domain, for example
portal.yourcompany.com? If not, it runs on an address we provide. - If you do, who manages your DNS? This is usually your domain registrar or IT team. In most cases all that's needed is two DNS records that we'll send you: one pointing the address at the portal and one proving you own the domain. We then issue and renew the security certificate for you at no extra cost.
- Does your organization require its own certificate? Some security policies, or wildcard domains, need a certificate you supply. If so, let us know who issues your certificates.
5. Who uses the portal
- Who are your portal users? For example customers, partners, members, suppliers or your own staff.
- How do they get an account?
- Anyone can sign up.
- Only people you invite.
- Only people who already exist as contacts in your Dataverse.
- Do your own staff need to sign in? Staff can sign in with their Microsoft work accounts, and their existing Dataverse security roles then apply.
- Roughly how many users do you expect? There is no per-user charge; this helps us plan.
6. How users sign in
We recommend Microsoft and Google accounts.
- They verify email addresses, so an account can be matched safely to an existing contact in your Dataverse.
- They are the easiest to set up from your side.
- Microsoft: we can help with the registration.
- Google: you create the sign-in credentials in your Google Cloud account and send them to us. We'll give you the exact settings to enter.
Other options are available if you need them:
- Email and password accounts, with email confirmation required before first use. These can also be switched off entirely.
- Facebook, which you set up and provide credentials for, as with Google.
Let us know which providers you want to offer.
7. What the portal does
- Which tables (data) should appear on the portal? For example cases, orders, invoices, applications or appointments.
- For each one, what can users do?
- Read only.
- Create new records, for example submitting a request or an application.
- Edit existing records.
- Delete records.
- Which records can each user see?
- Only their own.
- Everyone at their company.
- Records belonging to something they have access to, such as the cases on their account.
- Are there different groups of users with different access? For example customers and partners, or regular users and company administrators.
- What information do you want to collect from users? List the forms and the fields on each, and which are required.
- Do users upload or download documents?
- Do you want charts, or the ability to export lists to Excel?
8. Look and feel
- Your logo, ideally as an SVG or a high-resolution PNG.
- Your brand colour.
- A small icon for browser tabs (favicon), if you have one.
- The portal's name as it should appear to users.
- Which languages the portal should be available in.
- The pages you'd like, for example a home page, a help or FAQ page, and contact details. A rough sketch or a list is plenty.
9. Emails the portal sends
The portal sends emails such as sign-up confirmations and password resets through your Dataverse.
- Which address should they come from? For example
noreply@yourcompany.com. - Who can create a shared mailbox with that address in Exchange Online? It needs no licence, and takes your Exchange or Global administrator a few minutes in the Exchange admin centre. We set up and test everything on the Dataverse side once it exists.
10. Replacing an existing portal
If the new portal replaces an existing one, such as a Power Pages site:
- The current portal's address, and what it is used for today.
- Addresses people have bookmarked or that appear in emails and documents, so they keep working after the switch.
11. Legal and policies
- A privacy policy and terms of use for the portal, or links to your existing ones.
- Any cookie or consent wording your organization requires.
12. Timeline
- Your target go-live date, and any deadlines behind it.
- Any reviews the portal needs before launch, for example from your security or accessibility team.
Next steps
Send what you have so far to support@powerportalspro.com, or reply to your welcome email, and we'll arrange the kickoff call. Partial answers are welcome.
What the service includes, the access you give us and how we protect it are set out in the Full Service terms.
