Skip to content

Customer Onboarding

This procedure covers bringing a new customer onto Enclave, from creating their tenant through to verified connectivity.

Prerequisites

  • Access to the Enclave Partner Portal
  • The customer's company name and primary domain
  • An RMM tool or other method for deploying software to the customer's devices
  • A plan for the customer's initial use case (remote access, site-to-site, gateway access, etc.)

Procedure

1. Create the customer

In the Enclave Partner Portal, select Add Customer and complete the form:

  • Customer Name is the company name as it will appear in the Enclave Portal and on invoices.
  • Domain Name is the customer's primary business domain (e.g. trantor.example). The Partner Portal performs a DNS lookup during creation and rejects domains that do not resolve. The domain name is not used to configure the customer's Enclave network. Contact support if the customer does not have a resolvable domain.
  • Estimated Systems is the approximate number of agents the customer will need. This becomes the initial licensed seat count and billing baseline when the customer converts to paid. It is not a hard limit during the PoC; the customer can enrol more systems than this estimate.
  • Estimated Gateways is the number of gateway add-on licences needed (0 if not using gateways). Like estimated systems, this sets the initial billing baseline and is not a hard limit.

Add at least one admin. Choose between adding a Partner User from your organisation (immediate access) or inviting an External User by email. Consider enabling Automatically Add Partner Users if your entire team should have access to this customer's tenant.

The customer is created in Pending PoC state. The 14-day trial clock does not start until the first system enrols. See Customer Lifecycle for details.

2. Access the customer's tenant

Navigate to the Enclave Portal and select the customer's organisation. All remaining steps happen in the customer's tenant, not in the Partner Portal.

3. Plan your tag taxonomy

Before creating enrolment keys, decide on a tag naming scheme. Tags are lowercase, alphanumeric, with - and . as separators. See Tag and Policy Design for a recommended taxonomy and naming conventions.

Tags are labels on enrolled systems. At a minimum, consider tagging systems by:

  • Who uses the system (e.g. staff, engineers, contractors)
  • What the system does (e.g. servers, file-servers, workstations)
  • Where the system is (e.g. head-office, datacentre, client-site)

4. Create enrolment keys

Create purpose-specific Enrolment Keys for each category of device. Configure each key with:

  • Auto Tags matching the tag taxonomy from step 3
  • Use Limit matching the expected number of devices (to prevent key over-circulation)
  • Approval Mode set to Automatic if trust requirements will verify identity, or Gated for manual approval

For short-lived trial keys, set an Auto Expiry date aligned with the PoC end date.

Tip

Create separate keys for different device roles rather than one key for everything. For example, a Staff Laptops key with auto-tags staff and users, and a Servers key with auto-tag servers. This keeps your tag assignments clean from the start.

5. Deploy Enclave agents

Deploy the Enclave agent to the customer's devices using your RMM tool or preferred deployment method:

Warning

Installing Enclave directly on Active Directory domain controllers or other Windows servers running DNS services is not recommended. The additional network adapter can cause the server to register unintended DNS records, leading to unexpected behaviour. Use an Enclave Gateway adjacent to the server instead.

After deployment, verify that the enrolled systems appear in the customer's Enclave Portal with the correct auto-tags applied.

6. Create policies

Create Policies that define connectivity for the customer's initial use case. Follow the X for Y naming convention:

  • Servers for Staff so staff laptops can reach servers
  • File Server for Finance so the finance team can reach the file server
  • Office LAN for Remote Workers so remote staff can reach the office network via gateway

Configure Access Control Rules to restrict traffic to the required protocols and ports. The default rule allows all traffic; remove it and add specific rules for production use.

7. Configure trust requirements (optional)

If the customer uses an identity provider (Microsoft Entra ID, Google, Okta, etc.), add a User Authentication trust requirement to enforce identity verification before connectivity is established.

Trust requirements are configured in the customer's Enclave tenant. The setup effort depends on the identity provider:

No IdP-side configuration required:

  • Microsoft Entra ID: enter the customer's Azure Tenant ID in the Enclave Portal. No app registration needed.
  • Google Workspace: enter the customer's Google Workspace domain. No app registration needed.

IdP-side app registration required:

The following providers require an OIDC application to be created and configured in the customer's identity provider (redirect URIs, grant types, scopes). If you manage the customer's IdP, do this yourself; otherwise, provide the customer's IT team with the setup instructions from the relevant guide:

  • Okta: create an OIDC app integration and a custom authorization server
  • Duo SSO: create a Generic OIDC Relying Party application
  • JumpCloud: create a custom SSO application with OIDC
  • Custom OIDC: configure any OIDC-compliant provider

8. Deploy gateways (optional)

If the customer needs access to devices that cannot run the Enclave agent (printers, IoT, legacy systems, cloud databases), deploy an Enclave Gateway. See the Gateway Deployment guide for the three deployment models (Managed, Co-managed, Self-hosted) and their respective responsibilities.

9. Test connectivity

From a sender-side device, verify connectivity to a receiver:

  • Ping the receiver's Enclave hostname or IP address
  • Access the intended service (RDP, SSH, file share, web application)
  • Check connection state by running enclave status on the sender

Connections should show as Direct. If a connection shows as Relayed, traffic is being routed through Enclave's relay infrastructure rather than flowing peer-to-peer. Relayed connections still work but add latency and are subject to bandwidth limits. Common causes include firewalls blocking UDP traffic, symmetric NAT, or restrictive network configurations. See What are relayed connections? for an explanation of why this happens, and the Troubleshooting guide for resolution steps.

If connectivity fails entirely (no connection established), check Troubleshooting and verify that the required firewall ports are open.

10. Document and handover

The Enclave Portal already shows what is configured: the systems, tags, policies, and keys. A technician can read the configuration at any time. Systems, policies, and ACL rules all have description fields in the portal; use these to record the intent behind each item at the point of creation.

What the portal does not capture is the broader context: why this customer is set up the way it is, what drove the decisions, and what a colleague would need to know to manage it confidently.

Focus your PSA documentation on that context:

  • Why this tag taxonomy was chosen over alternatives
  • Why certain ports were restricted or left open
  • Why trust requirements are managed by you rather than the customer's IT team (or vice versa)
  • What the customer's initial use case was and how the deployment supports it
  • Which RMM tool and scripts were used, and any customer-specific deployment quirks
  • If a gateway is self-hosted: where it runs, who maintains it, and why that hosting model was chosen

Converting to paid

When the customer is ready to move from trial to a paid subscription, use the Convert to Paying Customer button on the customer's page in the Partner Portal. See Customer Lifecycle for the conversion steps and Billing for how invoicing works after conversion.

Last updated July 22, 2026