About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Treat onboarding as a set of acceptance gates: identify the correct customer tenant, establish sign-in and access rights, validate imported data, prove integrations and agree the production cutover. Keep production rate limits and resource controls enabled. Revoke sandbox credentials rather than carrying them into production.
The useful test is whether the intended staff can complete their business work with the correct data and permissions. A created account, successful sign-in or populated database proves only part of that outcome.
Define the customer's boundary first
Before provisioning, record the customer's organisation identifier, environment, region, contracted features, data owners and technical contacts. Identify who can approve access, data migration and go-live. Agree which integrations and external dependencies are in scope.
For a multi-tenant application, keep the organisation identifier distinct from display names or email-domain assumptions. Our recommendation is to test tenant routing and access using two synthetic tenants before onboarding real data. Test both permitted actions and attempts to read or change the other tenant's objects. Do not use customer production systems for these negative tests.
This checklist is an editorial workflow. It does not imply that a particular hosting product provides every component automatically.
Gate 1: distinguish sign-in from provisioning
Federated authentication and account lifecycle management solve related but different problems.
OpenID Connect extends OAuth 2.0 for authentication and supports sign-in using identity information. An application must still enforce its access decisions; knowing who signed in is not equivalent to granting every operation.
Microsoft's SCIM guidance describes SCIM as a user-management interface for provisioning users and groups. It can work alongside federation such as SAML or OpenID Connect. SCIM is not an alternative sign-in protocol.
Record two decisions separately: how people authenticate, and how accounts and group memberships are created, changed and disabled. Then define how those identities map to the application's roles and customer tenant.
Suggested acceptance checks are:
- An authorised test user signs in to the correct organisation with the intended role.
- A user without the required role cannot perform a privileged operation.
- Group or role changes reach the application as designed.
- Deprovisioning prevents new access, and existing sessions or tokens are handled according to the documented application policy.
- An emergency access route has named owners, appropriate protection and an audit trail.
Do not assume that deleting an identity immediately invalidates every existing application session. Verify the particular product's lifecycle, token and session behaviour before promising a revocation interval.
Gate 2: establish production naming and secrets
Assign an owner for DNS, the public hostname, TLS certificate renewal and endpoint monitoring. Confirm that the expected hostname reaches the intended tenant or application environment.
Use separate production and sandbox credentials. Grant integration accounts only the required operations and customer scope. Record credential storage, rotation and revocation ownership. Avoid copying a developer's personal account into a production integration.
Rehearse with test identities and controlled destinations. Email, payment, file-transfer and webhook tests must not create unintended customer transactions. Keep the test's target systems and allowed effects explicit.
Gate 3: validate data beyond row counts
Agree the data objects to migrate: records, attachments, relationships, configuration and any required audit history. Document formats, transformation rules, rejected-record handling and the target application version.
Row counts are a useful reconciliation signal, but equal counts do not prove equal meaning. Our recommended acceptance pack includes counts by object type, rejected records with reasons, sampled relationship checks, attachment availability and representative business queries. Validate important totals or balances where they are relevant to the application, using customer-approved rules.
Plan the initial copy and any later changes separately. A delta import needs a defined source of changes, ordering, repeat-run behaviour and reconciliation. Agree the write-freeze window and final acceptance before switching the system of record. Do not shorten a parallel run simply because the customer is regulated; choose its duration from the migration risks and validation evidence.
Use synthetic data for a rehearsal where possible. Any use of real personal information needs the applicable handling authority, access restrictions and retention controls.
Gate 4: keep integration controls active
For each API, VPN or file exchange, name its tenant binding, credentials, endpoints, expected volume, retry rules and failure owner. Test a representative successful transaction and controlled failures in the test environment. Check that a retry does not create an unintended duplicate business transaction.
OWASP API4:2023 describes the availability and cost risks of unrestricted API resource use. Production controls should cover the relevant resources, not just request counts: upload size, execution time, concurrency or expensive downstream operations may matter.
Keep approved production quotas and rate limits enabled and test their expected rejection behaviour with bounded test traffic. Disable or revoke sandbox keys. Do not disable production limits to make an onboarding test pass; resolve an incorrectly sized limit through an approved change with evidence.
Gate 5: prove the business outcome before cutover
Choose an acceptance owner on the customer's side and agree a small set of representative business journeys. Include ordinary users and restricted users, not only an administrator who can bypass permission problems.
For an illustrative order-processing system, the checks might cover creating an order, finding its attachments, completing an authorised approval, producing the expected report and passing the correct result to an integration. This is a proposed example, not a tested customer case.
Record the test environment, data set, results, unresolved defects and decision. If a required gate fails, keep the cutover pending and assign a corrective owner. Define how the business will continue using the existing system until the failure is resolved.
Before go-live, agree the cutover window, stop conditions, recovery plan and support contacts. After switching, verify the same important transactions and reconcile any final data changes. Do not retire the old system solely because the new login page is reachable. Retention and retirement require their own agreed conditions.
A compact onboarding record
| Gate | Evidence retained | Decision owner |
|---|---|---|
| Tenant and identity | Tenant mapping, role tests, lifecycle results | ISV identity owner and customer access approver |
| Data | Reconciliation, exceptions and sample business checks | Migration lead and customer data owner |
| Integrations | Scoped credentials, transaction and failure tests | Integration owners on both sides |
| Cutover | Acceptance decision, stop conditions and support contacts | Named customer and ISV decision makers |
Reuse the record for each customer while preserving any justified differences. Automation can prepare repeatable configuration; evidence must still show that this customer's deployment meets its requirements.
Software vendor hosting is the related service area for discussing the platform requirements. No specific NetLeverage onboarding package, identity capability or service guarantee is asserted here.
Limits and sources
The workflow is an editorial recommendation based on source research. No identity configuration, import, load test or customer cutover was executed for this article. Follow the documentation for the exact identity provider, application and migration tool before implementing it.
- Microsoft Entra: Develop a SCIM endpoint for provisioning, SCIM 2.0 and its relationship to federation; accessed 14 November 2026.
- Microsoft identity platform: OpenID Connect, authentication scope; accessed 14 November 2026.
- OWASP API Security Top 10 2023, API4: Unrestricted Resource Consumption, resource-control rationale; accessed 14 November 2026.
Learning notes
Authentication, account provisioning and application authorisation are separate checks. Production rate limits stay enabled. Data counts need business validation, and a failed acceptance gate must keep cutover pending.
This article was originally published on .