RapidValueDocs RapidValue.eu
Docs/Start here

Quickstart: prove the governance loop

The fastest useful RapidValue evaluation is not a tour of every screen. It is one complete, explainable loop: read a real system, classify what arrived, calculate what should exist, compare it with what does exist, and inspect the evidence for one decision.

This route deliberately keeps provisioning disabled until the model has been reviewed.

Before you start

You need:

  • a tenant where you have the IGA administrator role;
  • read credentials for one non-production connected system;
  • a small, representative population with at least one identity, account, entitlement and assignment;
  • an owner who can confirm whether one observed grant is expected.

Do not start with production write credentials. A read-only first pass separates model quality from provisioning risk.

1. Connect and test

Open Setup, add the connected system, select the correct connector and choose read-only or review mode. Test the connection before continuing.

The test proves reachability and authentication. It does not prove that the selected objects, filters and mappings are correct.

2. Discover and map

Run discovery, inspect the returned object types and adopt only the fields that belong in the canonical model. Confirm the correlation key explicitly. A field that merely appears in a sample response is not automatically authoritative.

For custom APIs, follow Generic REST. For packaged connectors, use the relevant page under Connector reference.

3. Review the model

Before activation, check:

  • account types and their classification filters;
  • the field used to correlate an account to an identity;
  • which objects are read-only and which can eventually be written;
  • the schedule and its timezone;
  • any upstream/downstream sync relationship.

Resolve every blocking review item. Record accepted limitations rather than hiding them with a broad filter.

4. Activate and run the first import

Activate the connector and run one import. The first run has no predecessor, so its entire population must not be presented as a sudden delta.

Inspect totals for accounts, entitlements, assignments, correlation and classification. If a count is surprising, stop here and correct the read model.

5. Inspect Expected versus Actual

Open reconciliation for one identity. Actual is what the import observed. Expected is recalculated from policy, roles, approved requests and explicit keeps. The difference is drift.

Open the explanation for one row and verify that its source, rule or approval is named. If a reviewer cannot follow the reason, the model is not ready for writes.

6. Add one governed decision

Create one narrowly scoped access policy or access request. Preview who and what it affects, route it to a real approver, and confirm that the resulting decision appears in Expected state and the audit trail.

Keep the connector in review mode. The objective is to prove the decision chain, not to maximize automation on day one.

7. Decide whether to enable writes

Enable a write capability only after:

  • read/write parity has no blocking finding;
  • safety limits are configured for the target system;
  • a rollback or compensating action is known;
  • the first write is limited to a test identity or entitlement;
  • the responsible owner has accepted the scope.

Continue with the implementation guide, safety limits and troubleshooting.

Did this answer your question?One click records the page; add detail by email if something is missing.

Try “tenant isolation”, “role mining” or “Entra”.