Setting Up Your First Client Tenant

A step-by-step walkthrough for MSPs provisioning their first client in Regentra — from creating the tenant and configuring access to connecting integrations and confirming the environment is ready for service delivery.

‍

What a client tenant is in Regentra

In Regentra, a tenant is a fully isolated environment for a single client organization. Each tenant has its own users, its own compliance data, its own ticket queue, its own policy library, its own password vault, and its own compliance score. Nothing is shared between tenants — a change made inside one client's environment has no effect on any other client in your portfolio.

As the MSP, you sit above all client tenants. From your MSP dashboard, you can see every client, switch into any tenant with a single click, and manage the portfolio from one place. Inside each tenant, you operate within that client's context — their tickets, their controls, their policies — as if it were a dedicated platform instance built just for them.

This structure is what makes Regentra built for MSPs rather than adapted for them. Every client gets a complete, contained environment. You get a single place to manage all of them.

What to have ready before you start

Tenant setup takes less than ten minutes once you have the right information in hand. Having these details ready before you begin avoids interrupting the setup to chase down answers.

• Client's legal organization name — used to create the tenant record and displayed throughout the client's environment.
• Primary contact details — the name and email address of the client's main point of contact. This person receives the initial admin account invitation and becomes the client-side administrator unless you configure otherwise.
• Industry and regulatory context — knowing whether the client operates in healthcare, financial services, government contracting, or another regulated sector tells you which compliance frameworks to adopt at setup rather than after the fact.
• Microsoft 365 tenant domain — if the client uses Microsoft 365, having their tenant domain ready allows you to configure the Entra ID integration during setup rather than returning to it later.
• Approximate user count — informs billing configuration and helps you set the right compliance seat tier from the start.

Before you create the tenant: Confirm you are logged into your MSP-level account, not a client tenant. Tenants created from inside an existing client environment are scoped to that client, not to your MSP portfolio. The new client option in the MSP dashboard is the correct starting point.

Creating the tenant

From your MSP dashboard, select the option to add a new client. Enter the client's organization name and primary contact email. Regentra creates the tenant immediately — provisioning the isolated environment, generating an admin user account for the primary contact, and triggering a password setup email to that address.

The new tenant appears in your client list straight away. You can switch into it from the dashboard before the client has completed their account setup, which means you can begin configuring the environment on their behalf without waiting for them to log in first.

Billing is activated at the point of tenant creation. The seat is recorded in your Regentra account and flows through to your Stripe billing automatically. You do not need to take a separate billing action to register the new client.

Adding users and assigning roles

Every person who will access the client's tenant — whether a member of your MSP team or a user on the client's side — needs a user account within that tenant. User accounts in Regentra are tenant-scoped: a technician on your team who works across multiple clients needs to be added to each relevant tenant separately, though their login credentials remain the same across all of them.

MSP team members

Add the technicians, compliance analysts, and account managers from your team who will be working inside this client's environment. Assign roles based on what each person needs to do. A technician managing service desk tickets does not need compliance approval authority. A compliance analyst submitting policies for review does not need billing access. Assign the minimum role that covers each person's actual responsibilities.

Client-side users

If the client will have direct access to their own compliance dashboard — as is common in co-managed compliance arrangements — add their internal users and assign appropriate roles. Client users typically operate as Analysts or Viewers: they can see their compliance posture, submit policy acknowledgments, and raise support tickets, but cannot approve policies or make configuration changes to the environment.

Role overview

Regentra uses role-based access control to define what each user can see and act on within a tenant. The primary roles and their key permissions are:

• Super Admin — full access to all platform features including billing, integrations, and tenant configuration. Typically assigned to the MSP account owner.
• Admin — broad operational access including user management, compliance configuration, and service desk management. Suitable for senior MSP team members managing the client relationship.
• Approver — can approve compliance policies and move them to Active status. This is the role that gives a policy its organizational authority — assign it deliberately.
• Analyst — can create and edit compliance content, submit policies for review, and manage tickets. The standard working role for compliance team members and client-side compliance contacts.
• Technician — focused on service desk operations. Can manage tickets, log time, and access the knowledge base and password vault. Does not have access to compliance configuration.
• Viewer — read-only access. Suitable for client stakeholders who need visibility into compliance posture or ticket status without the ability to make changes.

Connecting Microsoft 365 and Entra ID

If the client uses Microsoft 365, connecting their Entra ID tenant is the single highest-value configuration step you can take at setup. The integration pulls evidence automatically from the client's Microsoft environment and maps it directly to compliance controls — meaning your compliance score reflects real data from day one rather than a blank slate waiting for manual input.

Evidence collected automatically through the Microsoft 365 integration includes:

• MFA enrollment status for every user in the tenant
• Conditional access policy configuration and enforcement status
• Admin role assignments and privileged account inventory
• Device compliance status via Microsoft Intune
• Sign-in risk events and security alert history
• Password policy configuration and stale account detection

To connect the integration, navigate to the Integrations section within the client's tenant and follow the Microsoft 365 connection flow. You will need Global Administrator access to the client's Microsoft tenant to authorize the connection. Once authorized, the integration runs continuously — evidence is refreshed automatically, and any changes in the client's Microsoft environment are reflected in their compliance posture without manual intervention.

Why this step matters: MSPs who skip the Microsoft 365 integration at setup typically revisit it within the first two weeks when they realize how much manual evidence collection it eliminates. Setting it up at tenant creation means the compliance score is meaningful from the first time the client sees their dashboard.

Adopting a compliance framework for the client

Once the tenant is created and the Microsoft 365 integration is connected, adopt the compliance framework or frameworks applicable to this client. Navigate to the compliance section within the client's tenant, open the framework library, and select the frameworks that match the client's regulatory obligations.

If you collected the client's industry and regulatory context before setup, this step is straightforward: a healthcare practice gets HIPAA, a business seeking enterprise contracts gets SOC 2, a defense subcontractor gets CMMC. If you are unsure which framework applies, refer to the Getting Started with Compliance Frameworks article for a decision guide.

After adopting a framework, Regentra immediately generates the client's initial compliance score and gap report based on the evidence already collected through the Microsoft 365 integration. This gives you a concrete starting point to share with the client at their onboarding review — a real score backed by real evidence, not a placeholder.

If the client has multiple applicable frameworks, adopt all of them at setup. Cross-framework control mapping means that evidence collected for one framework is automatically attributed to shared controls in the others — there is no penalty for adopting multiple frameworks simultaneously, and doing so from the start gives you the most complete gap picture immediately.

Configuring the service desk for the client

The service desk configuration for a new client covers three areas that need to be in place before the first ticket arrives.

SLA policy

Assign the SLA policy that matches the client's service agreement. If the client is on a standard tier, apply the standard SLA policy. If they have custom response or resolution time commitments in their MSA, create a client-specific SLA policy before assigning it. SLA policies applied at the client level govern all tickets for that client — getting this right at setup prevents SLA mismatches that are harder to correct once tickets are in flight.

Automation rules

Configure any ticket automation relevant to this client: auto-assignment rules that route tickets to specific technicians, priority escalation triggers, and any notification rules tied to this client's preferences. Automation set at onboarding runs from the first ticket — automation added later applies only to new tickets, not retroactively.

Knowledge base

Create a client profile article in the knowledge base documenting the client's environment: key contacts, infrastructure overview, known quirks, and any recurring issues the team should be aware of. This article is not for the client — it is for your technicians. Any technician picking up a ticket for this client for the first time should be able to read it and have the context they need to work effectively without asking someone else.

Setting up the client portal

The client portal is the self-service interface the client uses to submit tickets, track their status, and — if configured — view their compliance dashboard. Setting it up takes a few minutes and makes a visible difference in the client's first impression of how your service is delivered.

Configure the following before sharing the portal link with the client:

• Portal subdomain — the URL the client will use to access the portal. This can be a Regentra-hosted subdomain or a custom domain under the client's own brand if white-labeling is part of your service offering.
• Branding — upload the client's logo and set any color preferences if you are providing a white-labeled portal. A branded portal looks like part of the client's own toolset, not a third-party tool you have signed them up for.
• Ticket submission options — configure which ticket categories are available through the portal and any intake fields specific to this client's environment or service agreement.

Once the portal is configured, share the URL with the client's primary contact and confirm they can log in, see their ticket history, and submit a test ticket. This confirmation is the last step before the tenant setup is complete.

Tenant setup checklist

Use this checklist to confirm everything is in place before considering the tenant fully configured.

• Tenant created with correct organization name and primary contact
• Primary contact has received and completed their account setup email
• MSP team members added with appropriate roles
• Client-side users added if co-managed access is part of the service arrangement
• Microsoft 365 integration connected and evidence collection confirmed active
• Applicable compliance frameworks adopted and initial gap report reviewed
• SLA policy assigned and confirmed against the client's MSA
• Ticket automation rules configured
• Client profile knowledge base article created
• Client portal configured with correct subdomain and branding
• Client primary contact confirmed able to log into the portal

A well-configured first tenant sets the pattern for every tenant that follows. The decisions you make here — role assignments, SLA policies, framework adoption, integration setup — become the template your team repeats across the portfolio. Taking the time to get them right on the first client is the most efficient investment in the quality of every client setup that comes after it.

‍