1. Identify owners and the initial use case
Record the business owner, technical owner and operational support contact. Confirm why the application is being onboarded: visibility, access reviews, automated provisioning or a combination. Identify the environments and populations in scope. Keep the business outcome separate from the technical mechanism so that the team can evaluate alternatives without losing the original objective.
2. Understand accounts and identity correlation
Determine the account identifier, relevant user attributes and rules for matching accounts to identities. Ask how shared accounts, service accounts, duplicate identities and dormant accounts are recognised. Agree how unmatched accounts are investigated and who owns that work. Validate a representative sample before assuming that the full data set can be correlated safely.
3. Make entitlements understandable
List permissions, groups or roles with descriptions and owners. Establish whether a permission is requestable, reviewable or assigned through a business rule. Identify privileged permissions and combinations that require additional checks. A reviewer should have enough context to understand what retaining or removing an entitlement means for the person and the application.
4. Confirm integration prerequisites
Document the supported interface, network path, authentication method, required permissions and non-production access. Agree how credentials will be handled and who maintains them. Confirm supported lifecycle operations and any application limits. Where the integration cannot carry out an action, define the manual fulfilment route and evidence of completion instead of implying automation exists.
5. Test complete outcomes
Test account creation or linking, updates, grants and removals as applicable to the agreed scope. Include expired access, missing attributes, an unavailable target and a failed operation. Check reconciliation against the target application so that a successful workflow message is not the only evidence. Record defects and decisions about release acceptance with the accountable owners.
6. Establish support before release
Confirm the monitoring process, incident route and application-owner responsibilities. Record scheduling, retry behaviour, known limitations and recovery procedures. Agree how a future change to the application or entitlement model will be assessed. Handover should make clear who owns the integration after the project team leaves.
Choose a sensible onboarding wave
Group applications by business risk, readiness and shared dependencies. A high-priority application may need discovery or data remediation before implementation can start. Track those preparatory actions separately from connector build work. Use early integrations to improve the questionnaire and test pack before repeating the process across a larger estate.
This is a practical starting point for discussion, not a substitute for your organisation’s policies or product-specific implementation documentation.