Access Reviews and Campaigns at Scale

On this page

• What the estate looked like
• Why flat-file reviews exist
• Campaign types you will use
• Rules the platform enforces
• The campaign factory
• Verifying before anyone launches
• Scoping reviews with tags and metadata
• Failure modes seen
• What SailPoint's documentation adds
• Actions

Access reviews were the part of the program with the most volume and the least product support. By the end the tenant held about 500 campaigns built from about 520 templates, and most of them were quarterly reviews of applications that had no live connector. This page covers how the review estate got that big, the decisions that shaped it, and the script that made it manageable.

What the estate looked like

Two things stand out. First, most reviews ran on flat files. For an application with no connector, the cheapest way to get its access into ISC is a CSV of user and entitlement, loaded through a delimited-file or SQL-loader source, then reviewed like any other source. Second, some of those sources were named per reviewer and per quarter. That looks like a source created for each review cycle (an inference from the names, so check your own tenant), which is why the source count reached the hundreds.

Why flat-file reviews exist

• The application cannot be integrated yet, but audit wants evidence of a periodic review now.
• The application is integrated read-only in a later phase, and the review is the bridge.
• The access list comes from a report the application owner already produces.

The trade-off is that a flat-file review is only as good as the file. Nothing keeps it fresh, nothing reconciles it to the real application, and the correlation to identities depends on a single column. Treat it as a review input, not as a system of record.

Campaign types you will use

Uncorrelated accounts never appear in an access campaign. If you do not run a source-owner campaign too, they are never reviewed, and they tend to be the riskiest accounts on the source.

Rules the platform enforces

• Reviewers cannot review their own access. ISC moves the item to the reviewer's manager. Expect "unexpected reviewer" noise and tell reviewers why.
• A campaign that selects nothing is created empty. It does not error. Either the accounts are uncorrelated or nobody holds the access.
• Reviewer names must be unique. A display name that matches two people fails. Use an email address.
• Reminders, escalation and reassignment are organisation-level settings, not per campaign. Set them before the first launch.
• A campaign decision does not always remove access. Revocation in a flat-file source only creates a task or a ticket. Say so in the reviewer instructions.

The campaign factory

Creating hundreds of campaigns by hand is not credible, and the mistakes (wrong source, wrong reviewer, a stale file) are only found after launch. We built a Python tool, driven by a workbook, to create them safely. The design is worth copying whatever language you use.

The workbook

Column header prefixes tell the tool what a column is, and they combine: I_ identifier, D_ display name, E_ entitlement, C_ correlation attribute. A column called I_D_UserName is both the id and the display name.

What a run does

1. Preflight. The workbook can be saved, the API login works, the file server login works, settings are valid. If any of this fails, nothing has changed.
2. Plan. Every source and every campaign row is validated: reviewer found, group exists, entitlement column present. A bad source is skipped and recorded, the rest go on.
3. Run, per source. Snapshot the source settings, schema and correlation. Upload a clean copy of the file. Update the source settings. Aggregate. Remove stale accounts. Create the campaigns.

Safety properties

Choices that mattered

• Correlation column by match rate. Rather than trusting the file's author, the tool tests the candidate columns (email, login name) against the identity cube and picks the one that matches most accounts.
• Stale account removal with a guard. Accounts in ISC but not in the new file are removed, unless that would exceed a configured percentage. This stops a truncated file from emptying a source.
• Wait for the identity refresh. After removing stale accounts, the tool waits before creating the campaign, otherwise the removed accounts are still in the review.
• Reviewer fallback. A blank reviewer means the user's manager. A governance group can be named instead.
• Add new attributes before removing old ones. ISC will not delete or rename an attribute that a correlation rule, identity profile or entitlement uses ("Object in use by another"). Adding first and removing last avoids the deadlock.

Verifying before anyone launches

The most valuable addition came later: after each campaign is created, still STAGED, compare it to the file it was built from.

1. Download ISC's own Campaign Status Report CSV for the campaign. If it cannot be produced, read the same facts from the review items through the API.
2. Read the flat file back from the file server, the one the source really loads, not the local copy.
3. Compare, for the campaign's own scope only.

Three numbers per campaign are put side by side: what the file holds, what should be in the campaign, and what is in it.

"Should be in the campaign" is the file minus what ISC cannot include: uncorrelated accounts for an access campaign, and the inverse for a source-owner campaign.

The evidence is kept: a per-campaign report, a discrepancy list with likely reasons and the original status CSV from ISC.

Limits of the check

• People are matched by display name. Two people with the same name collapse into one, which can hide an offsetting error.
• Entitlement values are matched ignoring case but counted exactly. ISC shows Lda and LDA as one value.
• User ids that differ only in case (USER01 and user01 in the same file) make ISC drop the rows of one spelling. The tool unifies them when it writes the file and reports any that were already loaded wrongly.
• ISC's CSV adds a leading apostrophe to values that start with -. The check removes it.
• Identity campaigns are not compared pair by pair.
• A campaign checked after launch is still compared, but decisions already made do not change the item list.

Scoping reviews with tags and metadata

Tags on entitlements (about 4,000 were tagged) and a governance metadata attribute marking the review population let search-based campaigns select exactly the entitlements in scope. One tag per client entity, for example, produces one campaign per entity without touching the template. A tag-based scope also survives new entitlements being aggregated, where a hand-picked list does not.

Failure modes seen

What SailPoint's documentation adds

• Reassignment (reassigning certifications): the reviewer gives a reason in the comments, ISC checks the person being certified will not end up reviewing their own access, and automated reassignment stops after four hops, leaving the item with the fifth person in the chain. Long chains of "not mine" therefore end up on someone by accident.
• No automatic reviewer failover after launch, according to community answers. Set up work reassignment for planned absences before the campaign starts.
• Reminders go to reviewers weekly until they finish unless reminder emails are disabled. Escalation behaviour for IdentityIQ is described at length in the community; confirm the ISC equivalent before promising reviewers one.
• Delimited files must be sorted by account ID, or a campaign can show one entitlement per account (see the connectors page). The factory's file writer should sort on the id column. Files over 500 MB are outside the documented comfort zone.
• API pacing. A factory that creates hundreds of campaigns shares the 100 requests per 10 seconds allowance per client ID and API version. Add backoff on 429 using the Retry-After header, and give the tool its own API client.
• A custom escalation workflow from the community handles 250 items at a time, which mirrors the parallel loop cap. If you build one, use a serial loop for larger sets.

Actions

• Decide per application whether it is reviewed on a live connector or a flat file, and record why.
• Create governance groups before campaigns reference them, with at least two people each.
• Automate campaign creation, always create STAGED, and add a dry run and a snapshot-and-restore from day one.
• Verify every campaign against its source file before launch. Keep the evidence.
• Run a source-owner campaign for uncorrelated accounts, or accept in writing that they go unreviewed.
• Set reminders, escalation and reassignment at the organisation level before the first launch.
• Tell reviewers what a revoke decision will and will not do on a flat-file source.