LCM-Triggered Access Reviews

Integrate Access Reviews with Lifecycle Management workflows

This guide explains how to create Access Reviews from Lifecycle Management workflows and troubleshoot common issues.

Lifecycle Management (LCM) policies can trigger Access Reviews automatically using the CREATE_ACCESS_REVIEW action. When a workflow runs and conditions match, Veza queues and creates an access review campaign based on the configured certification plan.

Overview

Use LCM-triggered access reviews to:

  • Automatically certify access when employees change roles (movers)

  • Review permissions before offboarding (leavers)

  • Validate access grants after onboarding (joiners)

  • Enforce periodic re-certification based on identity attribute changes

The sections below cover configuration options and troubleshooting for reviews created by LCM workflows.

Troubleshoot missing reviews

Common scenarios:

  • All results filtered: Veza created the review but then deleted it because all rows already appeared in recent in-progress reviews

  • Entity type mismatch: The policy identity type does not match the access review query, and no identity graph relationship exists to resolve it. Veza displays this error: "No matching node type found for identity type {type}"

  • Missing workflow configuration: The Access Review workflow is not configured or not linked to the policy

LCM-triggered reviews always run when a workflow executes, but Veza deletes the review if it has no results after filtering.

Veza compares each row against the last five in-progress reviews (by default) for the same workflow. The system excludes rows that appeared in any of those reviews. If all rows are excluded, Veza deletes the review rather than completing it with zero results. Veza does not send notifications for deleted reviews.

To verify a review was created and deleted:

  • Check Veza Events for the review creation and deletion

  • Review Lifecycle Management event logs for the workflow execution

  • Note: Deleted LCM-triggered reviews do not appear in the Reviews list (unlike manually-created empty reviews, which do appear)

circle-info

This behavior prevents duplicate review efforts and focuses reviewer attention on changed or new access. The comparison count (default: 5) is configurable by Veza support using the CertificationCountToExcludeUnchanged setting.

Understand unchanged result filtering

LCM and Rule-triggered Access Reviews automatically exclude unchanged results. Veza enables this setting by default, and you cannot disable it for these review types.

When Veza creates a review, it compares each row against the last five in-progress reviews for the same workflow (sorted by start time, newest first). The system excludes rows that appeared in any of those reviews, leaving only new or changed access to review.

This behavior:

  • Applies automatically to all LCM_TRIGGERED and RULE_TRIGGERED reviews

  • Compares against the last five in-progress reviews by default (configurable by Veza support)

  • Cannot be changed through the UI or API

  • Does not apply to manually-created or scheduled reviews

If filtering excludes all rows, Veza deletes the review rather than completing it with zero results. Veza does not send notifications for deleted reviews, but the deletion appears in Veza Events.

circle-exclamation

Resolve entity type mismatches

LCM-triggered access reviews require the policy identity entity type to match the entity type defined in the access review query. Veza resolves this match in the following order:

  1. Direct match in source node types: The policy identity type matches directly

  2. Direct match in destination node types: The policy identity type matches the destination

  3. Linked nodes through the identity graph: Veza follows graph relationships to find a connection (for example, WorkdayWorkerActiveDirectoryUser)

If none of these resolve, the review creation fails with the error: "No matching node type found for identity type {type}".

Example: If your policy tracks WorkdayWorker identities and your review expects ActiveDirectoryUser entities, Veza still creates the review successfully if there is a defined relationship (for example, WorkdayWorkerActiveDirectoryUser) in the identity graph. If no such mapping exists, the review creation fails.

Fix missing enriched identity columns

Access Reviews can include enriched columns that display additional identity attributes (such as department or manager from an HRIS system). However, Veza skips enrichment when the identity mapping is ambiguous.

When Veza skips enrichment:

If a single account or entity maps to multiple identity nodes in the graph (for example, one Active Directory account maps to two different WorkdayWorker records), Veza intentionally skips enrichment rather than arbitrarily choosing one.

Result:

  • Veza still creates the review successfully

  • Enriched columns appear but remain empty for affected rows

  • Veza logs a trace-level warning: "Skipping enriching nodes due to finding multiple linked nodes"

Resolution:

Review your identity mappings to ensure each account maps to a single identity. Ambiguous mappings often indicate data quality issues in source systems (such as duplicate employee records).

Customize review names

When creating access reviews through LCM workflows, you can configure a custom review name using attribute transformers. This is useful when a workflow creates multiple reviews and you need to differentiate them.

Common use case (Movers): When employees change roles, a single workflow run can trigger multiple access reviews. Custom names help reviewers identify which review corresponds to which change.

Transformer syntax:

Use curly braces to reference identity attributes:

  • Review for {name} → "Review for John Smith"

  • {department} Access Review - {name} → "Engineering Access Review - John Smith"

  • {job_title} Certification → "Senior Engineer Certification"

See Attribute Transformers for the complete transformer syntax reference.

Dry Run verification:

Custom review names appear in Dry Run results, allowing you to verify the name format before the workflow runs in production. This helps catch transformer syntax errors or missing attributes early.

Last updated

Was this helpful?