Imports and exports

What each run operation does against Okta, and what to watch out for.

Full Import

Keep a periodic full import in your schedule. It's the only operation that can detect an object permanently deleted from Okta, because a delta import can only report on objects Okta can still return.

Run one after changing the group import settings on the Global Parameters page, since those change which groups Okta is asked for.

Delta Import

The watermark is the Okta lastUpdated value. Groups carry lastMembershipUpdated as well, so a membership change is picked up even when the group profile itself has not changed.

A delta import can't confirm a permanent delete. Use a full import for that.

Export

Exports are not transactional, and this is worth designing around. A single object's export can involve several API calls, and any one of them can fail after the earlier ones have succeeded:

• A user can be created and its activation fail.

• A user can be created and a suspension fail.

• A group can be created and a membership assignment fail.

When a create reports an error, check Okta before retrying, as the object may have been created. Import and reconcile it rather than exporting the create a second time, which Okta will reject as a duplicate.

Rate limits

Every import and export consumes the Okta org's rate limit, and so does everything else using that org. The management agent has no way to reserve capacity.

Import cost is driven mostly by object count and by the per-object attributes: enrolledFactors and availableFactors each cost one call per user, and group member costs one call per group.

The management agent log records the enumeration and per-object processing time separately, which lets you tell a slow Okta listing apart from slow per-object processing. See reading import diagnostics. Page size and concurrency can be tuned from Advanced settings, but read the timings first.