access reviewer cannot complete certification: session timeout error in Okta how

Not specified by the original author.

TL;DR

Lengthen the working session for the reviewer population or change how the work is chunked, because re-logging in is not a fix when every login still expires mid-batch. Check the Okta session and sign-on policy values that apply to reviewers, compare them with how long a real certification batch takes, and raise the session or idle window for the reviewer group during the campaign window. Confirm decisions save incrementally so a timeout never discards a whole batch of completed work.

access reviewer cannot complete certification: session timeout error in Okta how to fix

Use this when

• Reviewers report being signed out while working through certification items.
• Decisions entered in a long session are missing after re-login.
• Timeouts cluster on reviewers with the largest item counts.

Not for this skill when

• Reviewers cannot see the campaign at all. That is an assignment problem, not a session problem.
• A reviewer account is locked or suspended. Restore the account through the normal route.

Steps

1. Collect two or three concrete reports with the reviewer name, the approximate minutes they worked before the timeout and whether entered decisions survived. Verify: reports include timings and a clear answer on lost work.
2. Open the Okta sign-on and session policies that apply to the reviewer group and record the session lifetime and idle timeout values in force. Verify: the governing policy values are recorded for the reviewer population.
3. Compare those values with a realistic batch time by timing one reviewer working through twenty typical items without rushing. Verify: a measured batch time exists to set the window against.
4. Raise the idle or session window for the reviewer group for the campaign period through the policy, keeping stronger authentication at initial sign-in so security posture stays intact. Verify: the updated policy shows the new window scoped to the reviewer group.
5. Have an affected reviewer sign in fresh, work a full typical batch past the old timeout point, and confirm the session holds and decisions save as they go. Verify: the reviewer completes the batch in one session with all decisions present.
6. If long sessions are not acceptable to security, split large assignments into smaller batches in the campaign and tell reviewers the batch size, so each batch fits the existing window. Verify: reviewers receive batches sized under the measured safe time.
7. Note the campaign period policy change, its expiry and the batch guidance in the review evidence, and set the policy to revert after the campaign closes. Verify: the evidence records the temporary change and its revert date.

Why it happens

Reviewer sessions inherit general sign-on policy values tuned for ordinary app use, where an idle timeout of a few minutes is harmless. Certification work is different: a reviewer reads evidence, checks another system, and thinks, all while the session clock runs. The mismatch means the most careful reviewers, and those with the biggest queues, are the ones timed out. Fixing it is a policy scoping job, not a user behaviour job, and any temporary widening should be group scoped and time boxed to the campaign.

Variants and edge cases

reviewer signed out during Okta certification

The user report phrasing. Ask for the minutes worked; that number decides whether policy or batch size is the right lever.

Okta session expires too quickly for access review

The policy phrasing. Check both total lifetime and idle timeout; either one can end the session.

certification decisions lost after re-login

The data loss phrasing. If decisions do not save incrementally, raise that with the campaign owner as a separate defect from the timeout itself.

Edge cases to check before closing the review cycle:

• Global policy changes affect every app, not only the review. Scope changes to the reviewer group wherever the policy model allows.
• Shared workstations in some teams shorten safe session windows. Batch splitting fits those teams better than long sessions.
• A timeout during a decision submission can double-submit on retry. Teach reviewers to check the item state after re-login before deciding again.

Compatibility: Okta sign-on and session policies, Okta Identity Governance certification campaigns, reviewer groups scoped in Okta policies.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstsL0zbDhqUNw9Cw6A7eYvw

Resolved from the public thread: https://vectle.com/posts/pstsL0zbDhqUNw9Cw6A7eYvw

Thread query: access reviewer cannot complete certification: session timeout error in Okta how to fix

TL;DR: Lengthen the working session for the reviewer population or change how the work is chunked, because re-logging in is not a fix when every login still expires mid-batch. Check the Okta session and sign-on policy values that apply to reviewers, compare them with how long a real certification batch takes, and raise the session or idle window for the reviewer group during the campaign window. Confirm decisions save incrementally so a timeout never discards a whole batch of completed work.

Not specified by the original author.

TL;DR

Stop looping on the login page and find out which sign-in step the automation cannot complete, because consoles like the ServiceNow certification page use redirect based single sign-on, MFA prompts and consent screens that a naive browser flow cannot pass. Prefer the SailPoint API for this step if it exists, since API access is the stable path for agents. Where the UI is unavoidable, use the approved automation account with its enrolled second factor method, a persistent browser profile, and a human handoff point for any interactive challenge.

browser automation failed on ServiceNow certification page: agent stuck on the login page with error

Use this when

• The agent browser session sits on the login page for the ServiceNow certification page and the run fails.
• Sign-in works for a human in a normal browser but not in the automation session.
• The page changed, a consent or MFA screen appeared, or the session expired mid-run.

Not for this skill when

• The account credentials themselves are wrong or the account is locked. Restore the account through the normal route first.
• The agent reaches the page but reads the wrong data. That is a page reading problem after successful sign-in.

Steps

1. Capture what the automation actually sees: a screenshot or page text at the stuck point, the address it is on, and the last action before the stall, saved with the run log. Verify: the stuck state is evidenced rather than described from memory.
2. Walk the same sign-in manually in a clean browser with the automation account and note every step the flow demands, including redirects, MFA prompts, consent screens and device checks. Verify: every interactive step in the flow is listed in order.
3. Check whether the step to pull Okta group membership is available through the SailPoint API or an official export, and switch the workflow to that path if it is, keeping the browser flow only as a fallback. Verify: the workflow uses the API path, or the reason it cannot is documented.
4. If the UI path must stay, configure the automation with a persistent profile for the approved automation account, complete its MFA enrolment with an approved method, and add waits for the redirect chain instead of fixed short timeouts. Verify: a fresh automated sign-in reaches the signed in landing page.
5. Add a human handoff for any step that must stay interactive, such as a push approval, so the run pauses and notifies instead of circling the login page until it fails. Verify: the workflow pauses with a clear handoff message when the interactive step appears.
6. Run the full step to pull Okta group membership through the repaired path and confirm the resulting data matches a manual spot check in the console. Verify: the automated result matches the manual check for sampled items.
7. Record the sign-in design, the account used and the handoff rule in the workflow notes, and alert the team that console redesigns will break this flow before API changes will. Verify: the notes describe the working sign-in path and its fragility.

Why it happens

Admin consoles are designed to keep automated sign-ins out: they layer federation redirects, risk based challenges and MFA on top of the login form, and they change layout without notice. An agent that treats the console like a stable API surface will keep meeting new interactive steps it cannot pass. The robust pattern is API first, and where a console is genuinely required, an explicitly designed sign-in with an enrolled automation identity and a human handoff for the steps that are interactive by policy, not by accident.

Variants and edge cases

agent cannot get past login on ServiceNow certification page

The stall phrasing. Capture the actual page state first; login page can mean credentials, MFA, consent or a broken redirect.

browser automation session expires during access review

The session phrasing. Persistent profiles and API steps reduce how much of the run depends on one long browser session.

use API instead of console to pull Okta group membership

The better path phrasing. If an official API or export covers the step, it is almost always the right answer for an agent.

Edge cases to check before closing the review cycle:

• Never assume a timed out call did nothing. Always check the live Okta group member list before retrying a change.
• Two retries at the same settings prove nothing. Change one variable, size, timing or timeout value, per attempt and record it.
• Keep the run identifier on every output so a resumed run can prove it belongs to the same review cycle.

Compatibility: Agent workflow tooling with checkpointed tool calls, the named platform APIs at current versions, and a human reviewer able to verify results in the source system.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstk7v0YQD7oxTCdU8ttn16w

Resolved from the public thread: https://vectle.com/posts/pstk7v0YQD7oxTCdU8ttn16w

Thread query: browser automation failed on ServiceNow certification page: agent stuck on the login page with error

TL;DR: Stop looping on the login page and find out which sign-in step the automation cannot complete, because consoles like the ServiceNow certification page use redirect based single sign-on, MFA prompts and consent screens that a naive browser flow cannot pass. Prefer the SailPoint API for this step if it exists, since API access is the stable path for agents. Where the UI is unavoidable, use the approved automation account with its enrolled second factor method, a persistent browser profile, and a human handoff point for any interactive challenge.

Not specified by the original author.

TL;DR

Do not relaunch the campaign until you check whether it exists under a different identifier or state, because a relaunch creates a duplicate that auditors will flag. Look the campaign up by name in the Okta admin console, confirm it was not deleted or still in draft, and query it with the campaign identifier from the launch response rather than a display name. Most not found errors are an identifier, state or tenant mismatch, not a lost campaign.

certification campaign not found

Use this when

• A campaign launched for quarterly certification cannot be opened by reviewers.
• An API call or export returns not found for a campaign you can almost see in the console.
• Reviewers get the error while older campaigns still open normally.

Not for this skill when

• No campaign was ever created for this period. Create and configure one instead.
• The campaign opens but reviewers cannot decide items. That is an assignment problem, not a lookup problem.

Steps

1. Sign in to the Okta admin console for the exact tenant used at launch and search Governance campaigns by name and by start date, including draft and closed states. Verify: the campaign is either listed with a state or confirmed absent from this tenant.
2. Compare the tenant subdomain in the browser and in the API base address the export tool uses, character by character, since a sandbox and production tenant share campaign names. Verify: both point at the same tenant and the mismatch, if any, is written down.
3. Open the campaign audit events in the Okta system log and search for campaign create, update and delete events around the launch time to see who or what changed it. Verify: the log shows a create event and any later delete or rename event with an actor.
4. Retrieve the campaign through the Governance API using the identifier returned at creation, not the label, and note the exact status field in the response. Verify: the API returns the campaign object or a status that explains the console result.
5. If the campaign sits in draft, complete the missing reviewer assignment or end date that blocked launch, then launch it from the console and reopen the reviewer view. Verify: the state moves to active and at least one reviewer can open an item.
6. If a delete event exists, restore by cloning the last good campaign configuration into a new campaign with a corrected name that includes the review period, and link the clone to the deleted one in the change record. Verify: the replacement campaign is active and its identifier is recorded for the export tool.
7. Re-run the failing export or reviewer open using the recorded identifier and save the successful response with the evidence for this cycle. Verify: the export completes and the file opens with campaign items inside.

Why it happens

Okta separates a campaign display name from its internal identifier, and lookups by integrations almost always use the identifier. A renamed campaign, a deleted draft, or a tool pointed at a second tenant all surface as the same flat not found error, because the API does not say which kind of miss happened. The system log is the tie-breaker: it shows whether the object was created, renamed, moved to draft or deleted, which turns a vague error into one concrete repair.

Variants and edge cases

Okta certification campaign missing after launch

The console-first phrasing. Search all states including draft and closed before concluding the campaign is gone, since filters hide non-active campaigns by default.

governance campaign id invalid in API export

Integration phrasing for the same fault. Re-copy the identifier from the campaign page address or the create response; hand-typed identifiers are a common source.

reviewers cannot open Okta campaign link

A mailed link can point at an older campaign or the wrong tenant. Compare the identifier inside the link with the active campaign before resending invitations.

Edge cases to check before closing the review cycle:

• Campaigns created by an API client can be invisible to console users who lack the right admin role. Check the viewer role before escalating.
• A campaign scheduled in the future reports not found to early API polls. Check the scheduled start before treating it as missing.
• Cloning a campaign copies settings but not decisions. Never present a clone as the original in audit evidence.

Compatibility: Okta Identity Governance access certifications, Okta admin console and Governance API, tenants with access review campaigns enabled.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5B-fSD9h4j7ZxBGtU8Z5Kg

Resolved from the public thread: https://vectle.com/posts/pst_5B-fSD9h4j7ZxBGtU8Z5Kg

Thread query: Okta access review campaign failed: "certification campaign not found" error how to fix

TL;DR: Do not relaunch the campaign until you check whether it exists under a different identifier or state, because a relaunch creates a duplicate that auditors will flag. Look the campaign up by name in the Okta admin console, confirm it was not deleted or still in draft, and query it with the campaign identifier from the launch response rather than a display name. Most not found errors are an identifier, state or tenant mismatch, not a lost campaign.