Release Notes

Quick Start

Step-by-step tutorial demonstrating the complete Access AuthZ workflow

This tutorial demonstrates the core Access Request API workflow through a practical SCIM integration example. You will:

  • Integrate Veza with a target system using SCIM-compliant APIs

  • Call Veza APIs to trigger granting or removal of entitlements (in this case, SCIM groups) to SCIM Users

  • Create users and modify attributes for existing users

You will also use APIs to configure system settings, get integration capabilities, and monitor request status.

This covers the standard workflow from initial configuration through user creation and group management:

  1. Veza Environment Setup: Enable Access Requests and configure auto-approval

  2. Lifecycle Management Configuration: Enable provisioning on an existing integration

  3. User Creation: Use an Access Request and sync identities configuration to create accounts

  4. Target Discovery: Query the Access Graph to find groups for assignment

  5. Relationship Management: Assign users to groups via Direct API

  6. Status Monitoring: Track request progress and completion

This guide demonstrates the complete workflow. For additional patterns and troubleshooting, see the FAQ and the endpoint documentation:

Prerequisites

Before starting, complete the Prerequisites and Setup guide.

Step 1: Identity the LCM datasource

List available LCM datasources:

Look for your integration in the response:

Save the id field for future requests.

Note: Some integrations include additional metadata in the response, such as supported attributes and required fields for SYNC_IDENTITIES actions. This information helps you construct valid entity_attribute_transformers for user creation requests.

Step 2: Create a user account

Create a new user account with the selected attributes using a direct Access Request:

Attribute Update Behavior:

This same operation can update existing user attributes:

  • Set continuous_sync: true (config level) to enable updating existing active users

  • Set continuous_sync: true on individual attributes to update them on existing users

  • Attributes with continuous_sync: false only apply to new users

  • Inactive users (disabled/suspended) are always updated when reactivated

The API locates existing users by fields marked with unique_identifier: true.

Expected Response:

Save the request id to monitor progress.

Understanding sync_config: The sync_config parameter is used for SYNC_IDENTITIES actions (creating, updating, or reactivating user accounts). For relationship management (adding users to groups), use target_entity_ids without sync_config.

  • create_allowed: true - Creates new users if they don't exist

  • continuous_sync: true - Enables updating attributes on existing active users

  • unique_identifier: true - Marks fields used to locate existing users (cannot change after creation)

Step 3: Monitor request status

Check if your user creation has completed:

When the job is successful, you will see:

Important for automation: When creating a new user with sync_config, the assignee_entity_id field is automatically populated after the user is created. This ID is typically used for follow-up operations such as assigning the user to groups (as shown in Step 5). You can use this value in future API calls without needing to query the Access Graph.

Possible states:

  • INITIAL - Request has been created

  • WAITING_FOR_APPROVAL - Request awaiting approval

  • NEEDS_MORE_INFORMATION - Approver requested more information

  • PLAN_SELECTED - Request is processing

  • COMPLETED - Request completed successfully

  • ERRORED - Check error_message field for details

  • REJECTED - Request was rejected

  • CANCELED - Request was canceled

  • JIT_REVOKED - Just-in-time access was revoked

  • EXTERNAL_RUNNING - External system is processing request

Step 4: Find available groups

To assign users to groups, you need to discover which groups exist in your target system and obtain their Veza entity IDs. Use the Query Builder API to find available groups:

Example response:

The id field is the Veza entity ID you'll use as the target_entity_ids in the next step.

Why query the Access Graph for target entities? Unlike assignee_entity_id (which is returned when you create a user), target entity IDs for existing groups and roles must use Veza's internal entity ID format. The Access Graph is the authoritative source for these identifiers.

Step 5: Assign user to group

Add your user to a group using the direct Access Request API:

Expected Response:

Monitor this request using the same method as Step 3.

Step 6: Remove user from group (Optional)

To finish testing the grant/revoke cycle, you can remove the user from the group:

Expected Response:

After the request completes (state: "COMPLETED"), verify in your SCIM server that the user has been removed from the group's members array.

Verification

Check the target application

Veza's Access Graph will not refresh until the next scheduled extraction, or you manually trigger an extraction. You can trigger an extraction in Veza by opening the integration details and clicking Start Extraction on the Data Sources tab.

In this example, we query the SCIM server to confirm the changes.

Verify the changes were made in your target system:

Look for the user in the response:

Verify the user attributes match the request:

  • userName should match your destination_value_formatter for user_name

  • displayName should match your destination_value_formatter for display_name

  • emails should contain your specified email address

  • active: true confirms the user is enabled

Check group members for assigned users:

The response should show:

  • The members array contains an entry with your user's ID

  • display matches your user's display name

  • The lastModified timestamp shows recent changes (after your API call)

  • $ref provides the direct link to the SCIM user resource

Troubleshooting:

  • If verification fails, check the Access Request state for errors

  • Unexpected attributes can indicate issues with entity_attribute_transformers values

  • Empty members arrays indicate that a group assignment has failed

  • lastModified timestamp can indicate when an operation may not yet be complete

Check request history

List all your access requests to see the complete history:

You have now completed the Access Request API example workflow!

Next steps

PreviousAccess AuthZ APIsNextPrerequisites

Last updated

Was this helpful?