Built-in post action handlers
This page describes every post action handler shipped with Omada Identity: what it does, when it runs, what it changes, and when it does not. For the general mechanism — the ISurveyPostActionHandler interface, how a post action is wired into a survey template, and how to build a custom one — see Post actions.
A post action handler acts on a survey object once it reaches the relevant point in the survey's workflow. Depending on how the post action is configured on the survey template (Run after routing, see Post action), and on whether the survey is closed before everyone has answered, this can mean:
- Only once the survey object completes its final workflow step.
- After every workflow step, if Run after routing is enabled.
- When the survey is closed prematurely, with some objects still unanswered.
Which of these apply, and what happens in each case, differ per handler — see the individual descriptions below.
Post action handlers are configured per survey template, not per feature. Several of the handlers below are pre-configured in Omada's out-of-the-box survey templates; you typically add or change only one yourself when building a custom survey template.
Shared behavior
Two classes provide behavior that other handlers build on. They are not post actions you configure directly on a survey template — you will not enter their class name in a survey template's Class field — but understanding what they provide helps explain what the handlers below have in common.
Common building blocks
Most handlers on this page share a common foundation that provides:
- Copying a configured list of survey properties onto the underlying data object (a
propertiesparameter). - Stamping a "last attested" date property with the current date and time, if one is configured (a
lastAttestedPropertyparameter). - Recognizing whether a proposed owner has accepted ownership, based on a configurable "accepted" answer (an
acceptOwnershipGuidparameter). Some handlers require this parameter; others always check against the built-in "Yes" answer regardless of what's configured — this is noted per handler below. - Recording Keep/Remove decisions in a shared survey-result tracking table (enabled with an
updateSurveyResultTableparameter), including a safeguard that treats a question left unanswered when the survey closes as "removed", with a standard audit comment ("Forced removed due to missing answer at survey closure"). - Applying an ownership decision — and, where applicable, an account type — to the account referenced by the survey.
Ownership transfer building blocks
ControlPolicySetOwnershipPostActionHandler and TransferOwnershipSurvey (below) additionally share the logic that decides how a new owner is actually written to an object:
- By default, the new owner is written to the standard owner property for the object's type: Identity or technical identity (via the manager/self-management setup), Org. unit (manager), Resource and Resource folder (owner, or manual owner if the previous owner is currently set as a manual owner), System (owner), or Constraint (owner).
- If the survey object includes the
SURV_OWNERPROPERTYproperty, the new owner is written directly to that named property instead, bypassing the standard type-based behavior. See Survey object and Data sources – Configurable ownership in surveys.
AccountOwnershipSurvey
Purpose: Confirms or rejects the proposed owner of an account. Ships with the Account ownership review survey template.
When it runs: Only once the survey object completes its workflow. It does not act on a survey that's closed prematurely — an ownership question left open when the survey is force-closed is left as-is.
Required configuration: a required acceptOwnershipGuid parameter identifying which answer counts as "accepted"; an optional createResourceAssignment parameter (true/false, defaults to false in the shipped template).
What it changes: records the ownership decision and, if accepted, the chosen account type. If createResourceAssignment is enabled, it also creates a resource assignment linking the new owner to the account — this is off by default, so out of the box, accepting a new owner updates ownership and account type without creating a separate assignment.
When it does nothing: if the ownership question has not been answered.
Resource-assignment creation only happens if you explicitly enable createResourceAssignment.
An orphaned account is discovered with no listed owner. An administrator proposes an identity as the new owner in the Account ownership review survey; once that identity accepts, the account's ownership and account type are updated. No resource assignment is created unless the survey template has createResourceAssignment=true.
GAASAccountOwnershipSurvey
Purpose: Confirms or rejects the proposed owner of an account — functionally similar to AccountOwnershipSurvey, but used by a separate account-ownership survey variant.
When it runs: only once the survey object completes its workflow; no action on premature closure.
Required configuration: a required acceptOwnershipGuid parameter.
What it changes: if accepted, and the proposed owner is a primary (non-technical) identity, it records the ownership decision and always attempts to create the corresponding resource assignment — reusing an existing account resource where one exists, or creating one automatically if it does not. Unlike AccountOwnershipSurvey, it does not set an account type, and resource-assignment creation cannot be turned off.
When it does nothing: if the ownership question has not been answered.
Does not set an account type; always attempts to create a resource assignment for a primary identity, with no configuration option to disable this.
A proposed owner accepts an orphaned account in a survey based on this handler. The acceptance is recorded, and the resource assignment linking the owner to the account is created automatically, without an account type being set.
ControlPolicySetOwnershipPostActionHandler
Purpose: Applies a proposed owner from a Control Policy exception survey to the object the exception is about (for example, a resource or system flagged by an "all resources/systems must have an owner" control policy). Used by the Manage control policy exceptions – Specify owner survey template, which backs control policies such as All resources must have an owner and All systems must have an owner.
When it runs: only once the survey object's workflow is complete; never on premature closure.
Required configuration: an ownershipMustBeAccepted parameter (true/false). It defaults to false, meaning the new owner is applied as soon as it is proposed and the step completes, without a separate acceptance step. Set it to true to require the proposed owner to explicitly accept before ownership changes.
Unlike the account-ownership handlers above, this handler always checks acceptance against the built-in "Yes" answer — configuring acceptOwnershipGuid has no effect here.
What it changes: writes the new owner onto the flagged object, using the standard owner property for that object's type (see Ownership transfer building blocks above), or the property named by SURV_OWNERPROPERTY if configured.
When it does nothing: if the workflow is not complete; if no proposed owner was set or it did not change; if ownershipMustBeAccepted=true and the proposed owner has not accepted; if the flagged object can no longer be found.
Does not remove a previous owner from the object (see TransferOwnershipSurvey for that); does not update attestation dates or the survey-result tracking table.
The "All resources must have an owner" control policy flags a resource with no owner and creates an exception. The exception's resolver proposes an owner in the resulting survey; once that step completes, the resource's owner is set.
TransferOwnershipSurvey
Purpose: Reassigns ownership of an object from a previous owner (typically a terminated identity) to a newly proposed owner. Powers the Transfer ownership survey — see Transfer ownership.
When it runs: only once the survey object's workflow is complete; not on premature closure — if the survey is force-closed early, neither the old nor the new owner is touched.
Required configuration: none beyond standard survey wiring; the previous owner to remove is taken from a survey scope variable set when the survey is initiated.
As with ControlPolicySetOwnershipPostActionHandler, acceptance is always checked against the built-in "Yes" answer — an acceptOwnershipGuid parameter has no effect here.
What it changes: writes the new owner onto the affected object and removes the previous owner, using the standard owner property for the object's type — Technical identity (system owner), Identity (manager), Org. unit (manager), Resource and Resource folder (owner, or manual owner), System (owner), or Constraint (owner) — or the property named by SURV_OWNERPROPERTY if configured.
When it does nothing: if the workflow is not complete; if no proposed owner was set or it did not change; if the proposed owner has not accepted.
If the survey was not set up with the previous owner in scope, the "remove old owner" step is simply skipped — the new owner is still added.
An identity that managed several organizational units and owned several resources is terminated. The Transfer ownership survey proposes new owners for each object; once each proposed owner accepts, that object's owner is updated, and the terminated identity is removed as owner.
OIS_ResourceAssignmentSurvey
Purpose: Applies a Keep/Remove decision (and any other surveyed changes) to a resource assignment and can expire it.
When it runs: when the survey object's workflow completes, or — if the survey is launched with its deprovision resource assignments with uncompleted questions setting enabled — also when the survey closes prematurely.
Required configuration: properties (comma-separated list of survey properties to copy back, for example VALIDTO,ROLEASSNSTATUS), lastAttestedProperty, updateSurveyResultTable. The premature-closure behavior is controlled by a survey setting configured at survey launch, not by a post-action parameter — see Post actions – Survey settings.
What it changes: copies the configured properties, stamps the attestation date, and — if the decision is "Remove" (or the survey closes prematurely with the deprovision-at-closure setting enabled) — sets the assignment's valid-to date to now and marks it Obsolete, unless it has already expired, appending an audit note. If a survey-result tracking key is present, it also records the outcome there, including the standard "forced removed" note when the closure-without-decision path is used.
When it does nothing: if the workflow is not complete and the deprovision-at-closure setting is not enabled. If the assignment has already expired, its dates and status are not touched again, though the audit note and result record are still written.
Does not queue the identity for a Role & Policy Engine (RoPE) recalculation itself — recalculating what should still be assigned relies on the normal RoPE cycle.
A resource owner reviews a resource assignment survey and marks an assignment "Remove". Once the review step completes, the assignment is expired immediately and flagged Obsolete, with a note recording who removed it and why.
ODW_ResourceAssignmentSurvey
Purpose: Records the outcome of a resource-assignment survey question — kept or removed, with the reviewer's comment — without changing the underlying resource assignment itself.
When it runs: on every step of the survey object's processing (it is not gated on workflow completion), as long as updateSurveyResultTable is enabled.
Required configuration: updateSurveyResultTable=true; relies on an ODWBUSIKEY survey property identifying the assignment in the Omada Data Warehouse (ODW).
What it changes: creates or updates a survey-result record for the assignment, capturing whether it was kept or removed, who decided, and their comment.
When it does nothing: if updateSurveyResultTable is not enabled, or the ODW business key is empty.
This handler never expires or otherwise changes the real resource assignment — it only records the outcome for reporting; use OIS_ResourceAssignmentSurvey if the assignment itself also needs to be expired when "Remove" is selected. Because it is not gated on workflow completion, on a multi-step survey it overwrites the recorded outcome at every step with whatever answer currently exists, not only the final one.
A resource assignment review surfaces assignment data sourced from the ODW. As reviewers mark items Keep or Remove, the outcome is recorded for reporting, while any actual deprovisioning is handled by a separate process reacting to that result.
OIS_ResourceMasterDataSurvey
Purpose: Applies reviewed changes to a resource's master data — proposed owner, selected properties, and description — once a resource master-data survey completes.
When it runs: only once the workflow is complete; not on premature closure.
Required configuration: properties (properties to copy back), lastAttestedProperty, and a required acceptOwnershipGuid — this handler does honor a configurable "accepted" answer.
What it changes: updates the configured properties on the resource, stamps the attestation date, updates the description if it changed, and — if the proposed owner changed and was accepted — writes the new owner directly onto the resource's owner property.
When it does nothing: if the workflow is not complete. The owner is left untouched if the proposed owner did not change or was not accepted; other configured properties and the description are still applied independently of the ownership decision.
Only works on Resource objects; unlike the dedicated ownership handlers above, it does not integrate with self-management or resource assignments, and it overwrites the owner property directly rather than explicitly removing a previous value.
A resource owner reviews and updates a resource's master data — description and classification-relevant properties — and confirms a new proposed owner in the same survey. Once submitted, all the changes are applied together.
CalculatedAssignmentVerdictSurveyPostActionHandler
Purpose: Turns a Keep/Remove decision on a Role & Policy Engine (RoPE) calculated resource assignment into a recorded "verdict" that RoPE takes into account going forward, and can immediately expire the related direct assignment on Remove. Used by the Access review for managers, Access review for resource owners, and User Mailbox access review survey templates.
For the full parameter reference — including verdictExpiresAfterDays, useVerdictLogicForMultiContextAssignments, dontCreateNegativeVerdictsForImplicitAssignments, and applyExpiresAfterDaysToRemoveVerdict — see Post actions – CalculatedAssignmentVerdictSurveyPostActionHandler survey settings. Two additional settings are not listed there:
| Setting | Description |
|---|---|
| actorRole | The role of the person answering (defaults to Manager); recorded on the verdict. |
| deprovisionUnansweredQuestions | When enabled, a question left unanswered because the survey closed prematurely is treated the same as an explicit "Remove": a Remove verdict is recorded, and the linked assignment is expired. |
Required configuration: the survey template must include the RESASSIGNMENT property. The handler uses it to obsolete the individual direct assignment that the reviewer removed, so that access granted through other direct assignments or through a business role is not affected. The built-in Access review for managers and Access review for resource owners templates include and populate this property. If you use a custom survey template, add and populate the RESASSIGNMENT property; otherwise, obsoletion might not work as intended.
When useVerdictLogicForMultiContextAssignments is enabled and reviewers disagree across the questions linked to the same assignment, no shared verdict is recorded for that assignment — but an individual "Remove" answer still immediately expires that reviewer's own linked assignment.
A manager reviews their team's access in an Access review for managers survey. Choosing "Keep" on an entry records an approval verdict; choosing "Remove" records a removal verdict and immediately expires the corresponding assignment.
RoleCertificationPostActionHandler
Purpose: Processes Keep/Remove decisions in a role certification survey — removing child resources from a role, or setting the role to expire, and keeping a certification log. Used by the Role certification survey — see Role certification survey.
When it runs: on every step (to keep the certification log and, where applicable, auto-complete related questions), and at survey closure to finalize the certification date and log for roles that received at least one decision.
Required configuration: a scope variable identifying the resource type being certified (must resolve to a Role); no additional parameters are required.
What it changes: on a "Remove" decision for a role's own question, sets the role to expire; on a "Remove" decision for one of its child resources, removes that resource from the role. Once every question for a role has a decision, it records the certification date and a log of what was kept and removed. It also auto-completes a child-resource question on behalf of an assignee who already made the same decision earlier in the survey, or when the role itself was already decided as "Remove".
When it does nothing: a "Keep" decision only updates the certification log — it makes no change to the role or its resources.
A role or child resource left unanswered when the survey closes prematurely is left completely untouched — no expiry, no removal — and a role that received no decisions at all gets no certification log entry either. This handler updates Omada Identity's own role data; it does not itself push a change to a connected target system — that's handled by the normal provisioning pipeline reacting to the updated role.
A role owner reviews a role certification survey covering a role and its five child resources. They keep three resources, remove two, and confirm the role itself should remain. Once all six questions are answered, the role's certification date is updated and its log records what was kept and removed; the two removed resources are taken out of the role definition.
TransferAssignmentsSurveyPostActionHandler
Purpose: Handles what happens to an identity's existing resource assignments — and RoPE calculated assignments — when the identity transfers between contexts (for example, between organizational units). Used by the Transfer identity assignments survey template — see Configure identity transfer.
When it runs: after every step of the survey object's processing, and always at premature survey closure — any assignment not yet decided when the survey is force-closed is treated as removed.
Required configuration: relies on a @ContextType scope variable set when the survey template is configured, and on the survey's standard Transfer / Remove / Remove with grace decision property; no separate handler parameters are required.
What it changes: for each assignment, based on the decision:
- Transfer – creates a new assignment for the identity's new context and expires the old one (or, for a calculated assignment, records an approval verdict for the new context). If the existing assignment is no longer active, the decision is automatically treated as Remove instead.
- Remove – expires the assignment (or records a removal verdict) once the final step completes.
- Remove with grace – schedules the assignment (or verdict) to expire on a chosen future date instead of immediately. Unlike Transfer and Remove, this takes effect as soon as it is chosen, on any step.
When it does nothing: on the survey's first step, it only prepares the survey object — no decision is evaluated yet. Transfer and Remove decisions on later steps only take effect once the final step is reached.
Does not support parent/child surveys. A "Remove with grace" date cannot be later than the transfer's own grace period.
An identity moves from one organizational unit to another. For each of the identity's resource assignments, the assignee decides to transfer it to the new organizational unit, remove it outright, or keep it active for a short grace period before removal. Once decided — or once the survey closes, for anything left undecided — the assignments are updated accordingly.
UpdateDataObjectSurveyPostActionHandler
Purpose: A generic, no-code post action that copies survey answers onto a related data object, using a configured copy rule to determine exactly which survey property maps to which destination property. Used, for example, as the standard post action for Control Policy exception surveys.
For full configuration steps, see Post actions – Update the Data object survey post action handler.
When it runs: only once the workflow is complete; it makes no change at all if the survey is closed prematurely.
This handler has no field-level logic of its own — exactly which object and which properties are updated is entirely determined by the copy rule you configure, not by anything in the handler itself.
A control policy flags a resource without a required compensating control. The exception survey lets an assignee record the status, comment, and selected compensating control; on completion, this handler copies those answers onto the exception object using the configured copy rule.
DeletedContextSurvey
Purpose: Records the outcome of a review into whether a context (such as an organizational unit, company, or cost center) that disappeared from the source HR data was genuinely deleted. Used by the Deleted Context Survey — see Avoiding unintentionally deleted contexts.
When it runs: at survey object initialization (to stamp when the review started) and once the workflow completes (to record the decision). It does not act at all if the survey is closed prematurely — the context's status is left unchanged in that case.
Required configuration: none beyond standard survey wiring.
What it changes: sets the context's status to "Deleted (Accepted)" if the reviewer approves the deletion, or "Deleted (Rejected)" otherwise.
When it does nothing: only on premature closure, as noted above.
A review question left unanswered when the step completes is treated the same as an explicit rejection — there's no separate "no decision made" outcome.
A context stops being delivered from the HR system and is marked Deleted. The Deleted Context Survey assigns Operation administrators to confirm the deletion. If they accept it, the context's status becomes "Deleted (Accepted)" and any assignment policies on it stop being effective. If they reject it, the status becomes "Deleted (Rejected)" and access remains in place until the context reappears from the HR system.
SurveyCompletePostActionHandler
Purpose: Fills in configured property values on a survey object automatically when the system force-closes a survey — for example, because it passed its deadline — rather than on an ordinary, on-time completion. Useful for making sure a deprovisioning-style question always has a value, even if the survey lapses before anyone answered it.
For configuration steps, see Post actions – Survey complete post-action handler.
When it runs: only when the survey is closed by the system — not by a person — for example, due to a deadline.
What it changes: sets each configured property to its configured value on the survey object, then completes the step. This happens regardless of whether the property already had an answer, so any values you configure are applied whenever the system closes the survey, not only when a question was left blank.
Never runs on a normal, person-driven survey completion or closure — only on a system-driven one.
A resource assignment survey configured with a deadline lapses because nobody answered it in time. When the system force-closes it, this handler sets the survey's action to "Remove" and adds a standard comment, ensuring the assignment is still processed as removed even though no one responded.
SurveyEventDefinitionPostAction
Purpose: Built-in framework handler that evaluates any Survey Event Definitions configured on the survey template and triggers their configured actions — such as sending a notification — when their conditions are met.
When it runs: automatically, on every survey event (creation, routing, completion, and closure) for any survey template that has at least one post action configured. You do not add this one yourself.
Required configuration: none directly on this handler; you configure the underlying event definitions and their conditions and actions on the survey object type instead. See Survey event definitions.
What it changes: whatever the matched event definition's configured action does (for example, sending an email notification) — this handler only evaluates conditions and dispatches to those actions.
When it does nothing: if no event definitions are configured or enabled for the survey, if a definition's condition does not match, or if a "first time only" rule means it has already fired.
On its own, this handler has no visible effect — its behavior is entirely defined by the event definitions you configure separately.
You configure an event definition to email a requester whenever their access request survey question is approved. This handler evaluates that condition on every relevant survey event and triggers the email action when it matches.
Analytics-only handlers (Omada Identity Cloud)
The following two handlers do not change any survey, identity, account, resource, or role data. They only forward survey activity to Omada Identity Cloud's analytics pipeline, and only take effect when running in Omada Identity Cloud — configuring them in an on-premises environment has no effect.
AccessRequestIntegrationPostAction
Purpose: Feeds access-request survey activity (creation, routing, decisions) into Omada Identity Cloud's analytics to support process-efficiency analytics for approval surveys.
When it runs: on survey object creation, closure, and each routing step — but only in Omada Identity Cloud.
Required configuration: add it as a post action with Run after routing enabled; no parameters are required. See Survey templates – Enabling process efficiency analytics in approval surveys.
What it changes: nothing in Omada Identity itself — it only sends analytics events.
Has no effect outside Omada Identity Cloud; does not influence the approval decision or the underlying resource assignment in any way.
An organization wants visibility into how long access requests take to approve. Adding this post action to the access request approval survey template feeds that survey's activity into Analytics without changing how approvals work.
RecertificationPostAction
Purpose: Feeds recertification and access-review survey activity into Omada Identity Cloud's analytics, to support Recertification KPIs in Advanced Analytics. Also keeps Omada's Operational Data Store (ODS) in sync when survey objects are deleted — see Post actions – Respond to survey object deletion.
When it runs: on survey object routing and reassignment, and on survey object deletion — but only in Omada Identity Cloud.
Required configuration: add it as a post action configured to run after every step, on a survey template whose survey object includes a resource-assignment property mapped to ODWBUSIKEY. See Post action – Survey template in Recertification.
What it changes: nothing in Omada Identity itself, other than keeping ODS records in sync on deletion — it does not process the certification decision.
Despite the similar name, this handler is unrelated to RoleCertificationPostActionHandler — it never removes a role or resource, and never changes certification data. It only reports on recertification activity for analytics, and has no effect outside Omada Identity Cloud.
An organization wants Recertification KPIs — such as the number of pending and completed recertification requests — to appear in Advanced Analytics. Adding this post action to the Access review for managers/resource owners survey templates, together with the required ODWBUSIKEY mapping, feeds that data through.