Step 1

The Application Owner Starts the Intake

Traditional onboarding starts with a handoff — someone on the IGA team contacts the application owner, schedules a discovery session, and then tries to extract the right information through interviews and follow-up. The process is slow, inconsistent, and heavily dependent on who’s asking the questions.

Onboard.id flips this. The application owner initiates the intake directly through a guided wizard. The wizard asks the right questions in the right order, prompting the application owner to provide information about how the application manages users, roles, and entitlements — exactly what SailPoint IIQ needs to know to govern it.

No ICAM engineer required to facilitate. No scheduling. No discovery meetings.

Step 2

The Platform Guides, Validates, and Clarifies

The intake wizard isn’t a static form. It adapts based on the application type, the integration method, and the answers the application owner provides. If something is missing or inconsistent, the platform flags it and asks for clarification before the intake progresses.

This built-in validation catches the gaps and ambiguities that typically cause rework in manual onboarding. Instead of an engineer discovering three weeks later that the entitlement mapping was incomplete, the platform surfaces the issue during the intake — when it’s fastest and cheapest to fix.

Step 3

Configuration File Generation

Once the intake is complete and validated, Onboard.id generates the SailPoint IIQ connector configuration file. This is the artifact that the IGA team needs to actually connect the application to the platform and begin governance.

In the traditional model, creating this configuration file is the work — the technical translation that requires ICAM expertise. In Onboard.id, it’s the output of a structured process that the application owner completed. The expertise is embedded in the platform’s intake logic, not in a specific engineer’s head.

Step 4

Audit-Ready Documentation

Every intake generates a complete, structured record: what was asked, what was answered, when it was completed, and by whom. This documentation isn’t produced as a separate effort — it’s a natural byproduct of the workflow itself.

For federal organizations with audit requirements, this matters. The question “how was this application onboarded, and by whom?” has a clear, documented answer. The access governance chain is complete from the start.

Step 5

Review and Continuous Management

Onboard.id maintains a review queue and dashboard that gives IGA administrators visibility into every application in the onboarding pipeline — what’s been submitted, what’s pending clarification, and what’s ready for deployment. Applications can be revisited and updated when they change, keeping governance current without starting the onboarding process from scratch.

The result is an end-to-end onboarding workflow that’s faster, more consistent, and more scalable than anything built on manual expert effort.