> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md). # Manage catalog definitions Configure catalog definitions to control how approved access requests are fulfilled, using application provisioning, ITSM tickets (ServiceNow or Jira), or REST, XML, or SQL actions. Catalog Definitions are pluggable fulfillment methods that determine how an Access Catalog item provisions access when a request is approved. Each catalog definition specifies the type of action taken on approval (and optionally on revocation), along with visibility rules, form fields for requesters, and catalog display settings. Catalog Definitions are managed under **Lifecycle Management** > **Access Requests** > **Catalog** (the **Catalog Definitions** menu item before Veza v2026.11.2), which opens the **Catalog Definitions** page. *** ## Overview While Access Profiles define *what* access is included in a catalog item, Catalog Definitions define *how* that access is fulfilled. A single catalog definition encapsulates: * **Type**: The fulfillment mechanism (application provisioning, an ITSM ticket, or a REST, XML, or SQL action) * **Visibility Rules**: Who can see the catalog item * **Form Fields**: Input fields that requesters must complete when submitting a request * **Catalog Display**: Name, description, icon, and recommended status for the Access Hub * **State**: Whether the definition is active (Enabled) or hidden (Disabled) Each catalog definition is associated with a Provisioning Policy (for action execution) and an Access Request Policy (for approval workflow). Both are configured in the **Details** step of the creation wizard, in the **Lifecycle Management Policy** and **Access Request Policy** fields. ### Creation flow To create a catalog definition: 1. Navigate to **Lifecycle Management** > **Access Requests** > **Catalog** 2. Select **Create**. The **Create Catalog Definition** modal appears. 3. Select a **Catalog Definition Type**, then select **Next** 4. Complete the six-step wizard: **Details**, **Labels**, **Custom Properties**, **Configuration**, **Visibility Rules**, and **Catalog Item Info** 5. Save the definition The type cannot be changed after creation in the console. To edit an existing definition, select it from the list and select **Edit** in the row actions menu. *** ## Catalog Definition types Every catalog definition has exactly one type, which determines the fulfillment mechanism executed when a request is approved. Veza supports six types, all selectable in the **Create Catalog Definition** wizard: * **Application**: Provision accounts and entitlements on a connected integration through Lifecycle Management. * **ServiceNow**: Create a ServiceNow ticket when a request is approved. * **Jira**: Create a Jira issue when a request is approved, and a second issue when access is revoked. * **Send REST Payload**: Execute a REST API call when a request is approved or revoked. * **Send XML Payload**: Execute a SOAP or XML over HTTP call when a request is approved or revoked. * **Send SQL Command**: Run a SQL statement against a target database when a request is approved or revoked. Each type is documented below. You choose the type once, in the initial **Create Catalog Definition** modal, and the console offers no way to change it after creation. ### Choosing the right type | Use Case | Recommended Type | | ------------------------------------------------------------------------------------------------- | --------------------- | | Provisioning accounts and entitlements on a connected Veza integration (such as AD, Okta, or AWS) | **Application** | | Creating tickets in ServiceNow for manual fulfillment | **ServiceNow** | | Creating Jira issues for manual fulfillment or external tracking | **Jira** | | Calling a custom REST API for fulfillment (webhooks, internal APIs, third-party services) | **Send REST Payload** | | Calling a SOAP or XML over HTTP endpoint for fulfillment | **Send XML Payload** | | Running a SQL statement against a target database for fulfillment | **Send SQL Command** | {% hint style="info" %} **Identity correlation**: Application-type definitions require the requesting user's LCM identity to be correlated with a user account in the target system, either through a prior LCM sync, an identity mapping configuration on the IdP, or a matching graph path. If no correlation exists, the access request is rejected at submission time. Only the Application type requires identity correlation. The ServiceNow, Jira, Send REST Payload, Send XML Payload, and Send SQL Command types do not. {% endhint %} ### Application Application-type catalog definitions use Lifecycle Management (LCM) provisioning to create accounts and assign entitlements on a connected integration. This is the most common type for automated identity provisioning. **Prerequisites for Application type:** Before creating an Application catalog definition, confirm the following: * The target integration is configured with write-level credentials for Lifecycle Management * The target integration has been extracted at least once (so target system users appear in the Access Graph) * The Provisioning Policy associated with the catalog definition has at least a Provision Account action configured for the target datasource, with `identity_attribute_mappings` on the policy mapping source identity properties to graph attributes * Users who request access have an identity correlation established with the target system, either through a prior LCM workflow sync, through [Custom Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md) configured on the IdP, or through matching attributes in the Access Graph {% hint style="warning" %} **Identity correlation is validated at request time.** When a user submits an access request for an Application catalog definition, the system immediately checks for a correlated target user. If no correlation is found (no synced entity, no graph path), the request is rejected with "No local user/account or synced identity found." This validation occurs before the request enters the approval workflow. {% endhint %} **Configuration fields:** | Field | Required | Description | | ---------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Data Source** | Yes | The LCM integration where accounts and entitlements are managed | | **Entity Type** | Yes | The entity type the catalog targets. The options are the entitlement types that the integration's [Manage Entitlements](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/manage-relationships.md) action can assign (for example, `AzureADGroup`), plus the non-human identity types that its [Provision Account](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md) action can create. Human user types, and resources that are neither entitlements nor non-human identities, are not offered. | | **Assignee Entity Type** | Yes | The identity entity type that receives access (for example, `ActiveDirectoryUser`) | | **Provision Account Action to Run** | No | LCM action used to create an account on the integration if one does not already exist. Selected from actions configured on the associated Provisioning Policy. If omitted, the definition only assigns entitlements to users who already have an account. | | **Deprovision or Delete Account Action** | No | LCM action that disables or removes the account. Selected from actions configured on the associated Provisioning Policy. Access Requests does not run this action: a revoke, whether manual or at the end of a time-bound grant, removes only the entitlement. See the note below. | | **Entitlements to Allow** | No | A list of entitlements that requesters can select from. If empty, all entitlements on the integration are available. | | **Entitlements to Disallow** | No | A list of entitlements explicitly excluded from requests. If empty, no entitlements are blocked. | | **Form Fields** | No | Additional input fields the requester must complete. A Provision Account action transformer reads a field with a `{$form_field.}` placeholder. | {% hint style="info" %} **Allow and Disallow lists**: If both lists are provided, the disallow list takes precedence. An entitlement that appears in both lists is excluded. {% endhint %} {% hint style="warning" %} **A disallow list alone does not filter the request form.** Veza checks both lists at submission, and returns "entitlement *\:\* is in the disallowed list" for a blocked pick. Only the allow list scopes the selector a requester browses. A Catalog Definition that uses **Entitlements to Disallow** on its own still lists those entries in the form. The requester sees the exclusion only after submitting. To keep an entry out of the request form, name the permitted ones in **Entitlements to Allow** instead of excluding the unwanted ones. {% endhint %} {% hint style="warning" %} **Integration extraction prerequisite**: The entitlement list in the request form is populated from the target integration's Lifecycle Management datasource. If the integration has not completed at least one successful extraction with provisioning enabled, the Entity Type dropdown shows "This data source has no non-user entity types available. Choose a different data source." and the entitlement selector in the request form is empty. Verify the integration shows **Success** status under **Lifecycle Management** > **Integrations** before creating Catalog Definitions. {% endhint %} {% hint style="info" %} **Available starting with Veza v2026.10.5.** A completed request for an Application catalog item offers **Revoke Access**, the same as the other catalog types. Earlier releases do not offer the action for this type, and an expiring grant can also disable the account that the request created. A revoke, whether manual or when the JIT duration on the Access Request Policy expires, removes only the entitlement that the request granted. The account remains, because another grant on the same account might still need it. The Deprovision or Delete Account Action on the definition does not run. To remove the account, use a Lifecycle Management workflow, such as a leaver workflow. If the request only created an account and granted no entitlement, **Revoke Access** is disabled with the tooltip "There is nothing to revoke for this request." The other five types also offer **Revoke Access** on a completed request. Only a Jira definition checks its revoke configuration first: without a **Revoke Jira Integration**, the action is disabled with the tooltip "Revoke is not configured on this Catalog Definition. Configure revoke on the Catalog Definition before revoking access requests." {% endhint %} **Use Application type when:** You want Veza to provision user accounts, and to grant and revoke entitlements, directly on a connected application through LCM. ### ServiceNow ServiceNow-type catalog definitions create a ticket in a connected ServiceNow instance when a request is approved. This is intended for organizations that use ServiceNow as their ITSM platform for fulfillment. **Configuration fields:** | Field | Required | Description | | -------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **ServiceNow Integration** | Yes | A Veza Action of type ServiceNow, selected from your configured integrations. This determines which ServiceNow instance receives the ticket. | | **Headline Template** | No | The ticket short description. Supports the placeholders in [Ticket template placeholders](#ticket-template-placeholders). Type `{$` to insert form field values (for example, `{$form_field.justification}`). | | **Message Body Template** | No | The ticket description. Supports the same placeholders as the headline template. | | **Form Fields** | No | Additional input fields the requester must complete at request time. Field values can be referenced in the headline and message body templates using `{$form_field.}`. | Both the headline and message body also accept access-request placeholders. See [Ticket template placeholders](#ticket-template-placeholders). **Use ServiceNow type when:** Access fulfillment is handled by a ServiceNow workflow rather than direct LCM provisioning, and you want approved requests to automatically generate ServiceNow tickets. ### Jira Jira-type catalog definitions create a Jira issue when a request is approved. To make the access revocable, including time-bound access that expires, the definition also needs a Revoke Jira Integration, which creates a second issue when access is revoked or expires. Ticket creation uses a Jira Veza Action (a configured Jira notification integration), through the same Veza Actions framework used for ServiceNow. {% hint style="info" %} Automatic ticket creation for Access Requests is supported for ServiceNow and Jira. Only Jira can also create a revoke issue. For the supported-systems matrix, including the **Other** link type for externally created tickets, see [Configure ITSM integration](/4yItIzMvkpAvMVFAamTf/features/access-request/configure-itsm-integration.md). {% endhint %} **Configuration fields:** | Field | Required | Description | | -------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Jira Integration** | Yes | A Veza Action of type Jira, selected from your configured integrations. Determines which Jira project or instance receives the issue and supplies the grant notification. | | **Headline Template** | No | The Jira issue summary. Supports the placeholder grammar described below. Type `{$` to insert form field values. | | **Message Body Template** | No | The Jira issue description. Supports the same placeholder grammar as the headline. | | **Form Fields** | No | Additional input fields the requester completes at request time. Field values can be referenced in the headline and message body using `{$form_field.}`. | | **Revoke Jira Integration** | No | A Veza Action of type Jira used to create the revoke issue. Required to revoke access granted through this definition or to allow time-bound requests; see the note below the table. | | **Revoke Headline Template** | No | The summary for the revoke issue. Requires a Revoke Jira Integration. | | **Revoke Message Body Template** | No | The description for the revoke issue. Requires a Revoke Jira Integration. | {% hint style="warning" %} **Select a Revoke Jira Integration if access granted through this definition must be revocable.** With no Revoke Jira Integration, Veza refuses to revoke requests for this definition and rejects requests for time-bound access to it. If you set a revoke headline or message body, you must also select a Revoke Jira Integration, or the definition cannot be saved. {% endhint %} **Revoke lifecycle.** When access is revoked, either manually or when a time-bound duration expires, the request moves from Completed to Revoke Selected, and then to Revoke External Running once the revoke issue exists in Jira. Veza polls that issue on a configurable interval, five minutes by default, and waits for an administrator to resolve it: * Resolving the issue as Done moves the request to JIT Revoked. The revocation is complete. * Resolving it as Won't Do, or any other canceled-equivalent status, returns the request to Completed and clears the revoke link. **The access is still live**, and the request can be revoked again. The request history records the status the administrator chose. Requesters can re-request access while a revoke issue is still open, without waiting for it to close. **Use Jira type when:** Access is tracked or fulfilled in Jira, and you want approved requests and revocations to generate Jira issues. ### Ticket template placeholders The ServiceNow and Jira headline and message body templates share the same placeholder grammar. Each placeholder is substituted when the ticket is created: | Placeholder | Resolves to | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | | `{$form_field.}` | The value of a form field defined on the catalog definition | | `{$access_requestinfo.requestedFor}` | Who the access is for: the assignee name, falling back to the assignee ID, then the beneficiary's display name or email, then the submitter | | `{$access_requestinfo.requestedBy}` | The submitter's display name, falling back to their email, then their user ID | | `{$access_requestinfo.comments}` | The business justification (the Comments or Reason value) | | `{$access_requestinfo.id}` | The access request ID | | `{$access_requestinfo.target}` | The target entity type and the target names or IDs | ### Send REST Payload Send REST Payload catalog definitions execute a named Send REST Payload action from a Provisioning Policy when a request is approved. This type provides maximum flexibility for custom integrations and workflows that are not natively supported. Unlike the Application type, Send REST Payload does not require identity correlation between the requester and a target system user. The REST call is executed regardless of the requester's mapped accounts. **Configuration fields:** | Field | Required | Description | | ---------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Grant Action Name** | Yes | A Send REST Payload action from the associated Provisioning Policy, selected from a dropdown. Executed when access is granted or approved. | | **Revoke Action Name** | No | A Send REST Payload action from the associated Provisioning Policy. Executed when access is revoked or expires. | | **Form Fields** | No | Additional input fields the requester must complete. Veza substitutes each value into the matching `{$form_field.}` placeholder in the grant or revoke action's JSON payload. Veza adds nothing to the payload on its own, so a field that no placeholder references is not sent. | {% hint style="info" %} **Grant and Revoke actions** must reference named actions that already exist on the associated Provisioning Policy. The actions must be of type Send REST Payload. {% endhint %} To send a form field value, reference the field by name in the Send REST Payload action's JSON payload, inside a JSON string. For example, with form fields named `role_name` and `role_id`: ```json {"roleName": "{$form_field.role_name}", "roleId": "{$form_field.role_id}"} ``` Other forms, such as `$role_name` or `{role_name}`, are not form field placeholders. For the full substitution rules, see [Form field substitution](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md#form-field-substitution-access-requests-only). **Use Send REST Payload type when:** You need to call a custom REST endpoint (webhook, internal API, or third-party service) to fulfill or revoke access. ### Send XML Payload Send XML Payload catalog definitions execute a named Send XML Payload action from a Provisioning Policy when a request is approved, and optionally another action when access is revoked or expires. SOAP and XML transport runs over HTTP, so this type mirrors Send REST Payload. Like Send REST Payload, it does not require identity correlation between the requester and a target system user. **Configuration fields:** | Field | Required | Description | | ---------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Grant Action Name** | Yes | A Send XML Payload action from the associated Provisioning Policy, selected from a dropdown. Select the **Lifecycle Management Policy** first. Executed when access is granted or approved. | | **Revoke Action Name** | No | A Send XML Payload action from the associated Provisioning Policy. Executed when access is revoked or expires. | | **Form Fields** | No | Additional input fields the requester completes. Field values are XML-escaped and substituted into the XML payload template when the grant or revoke action runs. | {% hint style="info" %} **Grant and Revoke actions** must reference named actions that already exist on the associated Provisioning Policy. Both must be of type Send XML Payload. {% endhint %} **Use Send XML Payload type when:** You need to call a SOAP or XML over HTTP endpoint to fulfill or revoke access. ### Send SQL Command Send SQL Command catalog definitions execute a named Send SQL Command action from a Provisioning Policy when a request is approved, and optionally another action when access is revoked or expires. The action runs a SQL statement against the target database configured on the Provisioning Policy. Like Send REST Payload, it does not require identity correlation between the requester and a target system user. **Configuration fields:** | Field | Required | Description | | ---------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Grant Action Name** | Yes | A Send SQL Command action from the associated Provisioning Policy, selected from a dropdown. Select the **Lifecycle Management Policy** first. Executed when access is granted or approved. | | **Revoke Action Name** | No | A Send SQL Command action from the associated Provisioning Policy. Executed when access is revoked or expires. | | **Form Fields** | No | Additional input fields the requester completes. Field values are bound as SQL parameters when the grant or revoke action runs. | {% hint style="info" %} **Grant and Revoke actions** must reference named actions that already exist on the associated Provisioning Policy. Both must be of type Send SQL Command. {% endhint %} {% hint style="warning" %} Form field values are passed as bound SQL parameters, not concatenated into the statement text. Define the SQL statement and its parameters in the Send SQL Command action on the Provisioning Policy. {% endhint %} **Use Send SQL Command type when:** You need to run a SQL statement against a database to fulfill or revoke access. *** ## State management Each catalog definition has a state that controls its availability: | State | Behavior | | ------------ | ------------------------------------------------------------------------------------ | | **Enabled** | Active and visible to requesters in the Access Catalog (subject to visibility rules) | | **Disabled** | Hidden from the Access Catalog. The definition still exists and can be re-enabled. | To change a definition's state, use the **Enable** or **Disable** action from the row actions menu in the Catalog Definitions list table. The state toggle is not part of the create or edit form. Complete all configuration first, then enable from the list view. {% hint style="warning" %} **Disabled is the default.** A catalog definition created through the API without an explicit state is Disabled, and stays hidden from the Access Catalog until someone enables it. If a definition you created programmatically does not appear for requesters, check its state before looking at the visibility rules. {% endhint %} *** ## Visibility rules Visibility rules control which requesters can see the catalog item associated with a catalog definition. Visibility can only narrow the audience to a subset of the identities already in scope of the associated Provisioning Policy: a catalog definition governed by one policy does not reach an identity governed by another, whatever mode is set. A catalog definition has one of three visibility modes. The **Visibility Rules** step of the wizard exposes two of them, **All** and **Filter Strings**. The third mode, **Settings**, is the underlying default value and is not offered in the wizard. ### All When set to **All**, the catalog item is visible to every identity in the scope of the associated Provisioning Policy. This is the mode the wizard selects for new catalog definitions, and it suits broadly available resources (for example, a general IT support catalog item). ### Filter Strings (SCIM filters) When set to **Filter Strings**, visibility is determined by evaluating one or more SCIM filter expressions against the LCM identity of the user browsing the catalog. If the requester's identity matches any of the provided filters, the catalog item is visible. Multiple filters are evaluated using OR logic. If the mode is set but no filter expression is supplied, no identity matches, and the catalog item is visible to nobody. This mode enables fine-grained, attribute-based visibility. For example, you can restrict a catalog item to users in a specific department or location: * `department eq "Engineering"` * `location eq "US-West" or location eq "US-East"` In the wizard, select **Add Filter** to add each expression, and **Show Matching Identities** to preview the identities that a set of filters resolves to. {% hint style="warning" %} SCIM filter expressions evaluate against the LCM identity record of the requester. Make sure the identity attributes you reference are populated and kept in sync by the identity source. {% endhint %} {% hint style="info" %} **SCIM filter targeting is specific to catalog definitions.** Access Profiles have no per-item equivalent: their catalog audience is governed only by the global filters described in [Global requestable settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#global-requestable-settings). When you need attribute-based targeting of an individual catalog item, use a catalog definition in **Filter Strings** mode. {% endhint %} ### Settings **Settings** does not restrict visibility. A catalog definition in this mode is visible to every identity in the scope of the associated Provisioning Policy, with the same result as **All**. **Settings** is the default value of the visibility type, which has a practical consequence: a catalog definition created through the Veza API without an explicit visibility type receives **Settings**, as does one created with no visibility rules at all. Either way, the catalog item is visible to the whole policy scope. To restrict who can see a catalog item created through the API, set the visibility type to **Filter Strings** and supply the SCIM filter expressions. The label and Access Profile type filters in [Global requestable settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#global-requestable-settings) are not consulted for a catalog definition in any visibility mode. Those settings determine which **Access Profiles** are requestable and have no effect on catalog definitions. Catalog definitions in this mode show **Settings** in the **Visible To** column of the Catalog Definitions list. *** ## Form fields Form fields define input that requesters must provide when submitting an access request for the catalog item. Administrators configure form fields as part of the catalog definition, and requesters see these fields in the Access Catalog request form. ### Field properties Each form field has the following properties: | Property | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------ | | **Name** | A unique key for the field, referenced as `{$form_field.}` in transformers and REST payload templates | | **Type** | The data type of the field (see types below) | | **Description** | Help text displayed to the requester | | **Default Value** | A pre-filled value. If a default is provided, the field is optional. If no default is set, the field is required. | | **Allowed Values** | An optional list of permitted values, displayed as a dropdown. When set, the requester must choose from this list. | ### Field types | Type | Description | | ---------------- | ---------------------------------------------------------------------------------------- | | **STRING** | Free-text string input | | **BOOL** | Boolean (true/false) toggle | | **DATE\_TIME** | Date and time picker | | **STRING\_LIST** | A list of string values. Combined with **Allowed Values**, it renders as a multi-select. | | **NUMBER** | Numeric input | ### How form field values are used Form field values submitted by the requester are stored with the access request and can be used differently depending on the catalog definition type: * **Application**: Form field values feed the Provision Account action through `{$form_field.}` placeholders in its attribute transformers, which lets a requester supply account-specific information such as a preferred username or a cost center. The values do not override synced properties on their own: an administrator has to reference the field in the transformer for it to reach the target system. Referencing a field also makes it mandatory. Veza collects every form field named by the action's transformers and rejects a submission that leaves one empty with no default, reporting "required form fields referenced in action transformers are missing". * **ServiceNow**: Form field values are included in the ServiceNow ticket and can be referenced in the headline and message body using `{$form_field.}`. * **Jira**: Form field values are included in the Jira issue and can be referenced in the headline and message body using `{$form_field.}`. * **Send REST Payload**: Form field values are substituted into `{$form_field.}` placeholders in the action's JSON payload, not into the URL or headers. See [Form field substitution](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md#form-field-substitution-access-requests-only). * **Send XML Payload**: Form field values are XML-escaped and substituted into the XML payload template when the grant or revoke action runs. Veza re-checks that the payload is still well-formed after substitution and fails the request if it is not, rather than sending malformed XML to the target. * **Send SQL Command**: Form field values are substituted into the action's bind parameters when the grant or revoke action runs, and not into the statement text. Veza rejects a statement body that contains a form-field placeholder when the action is saved. Because bind parameters travel separately from the statement, the values need no SQL escaping and cannot alter the statement. *** ## Request form options The **Details** step includes a **Request form settings** group that adjusts how the shared submission form behaves for this catalog item. These options change the requester-facing form only; they do not change what is provisioned. | Option | Description | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Make "Comments" optional** | By default, requesters must complete the Comments field before submitting. Turn this on to let them submit without it. This is a form-level hint only: the backend does not validate the comment either way. | | **"Comments" field label** | Overrides the label of the Comments field on the request form. Leave empty to use the default "Comments" label. A common override is "Business Justification". | | **Hide the "Explanation" field** | The Explanation field is a dropdown of preset reasons configured in [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md). Turn this on to remove it from the request form for this catalog item. Unlike the Comments option, this also relaxes server-side validation, so an explanation is no longer required for requests against this definition. | *** ## Catalog display settings Configure how the catalog item appears in the Access Hub under the **Catalog Item Info** step of the wizard. A **Preview Catalog Item** button at the bottom of this step shows how the item appears to requesters. | Field | Description | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Display Name** | The name shown to requesters in the Access Catalog | | **Short Description** | A brief headline describing the catalog item | | **Detailed Description** | A longer description rendered in the item detail view, supporting standard markdown | | **Mark as recommended** | A toggle that lets the item appear in the **Recommended** section of the Access Catalog. See [Using the Recommended flag](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md#using-the-recommended-flag). | | **Icon** | An image displayed alongside the catalog item name | {% hint style="info" %} **Catalog Editor shortcut**: You can also update the icon, detailed description, and recommended flag directly from the Catalog Definitions list table by selecting **Catalog Editor** from the row actions menu, without entering the full edit form. {% endhint %} As a general guideline, write clear, concise names and descriptions. Requesters browse the Access Catalog to find the right access, and descriptive catalog items reduce misdirected requests and approval delays. *** ## Custom properties and labels Catalog definitions support two mechanisms for organization and metadata: * **Labels**: A list of opaque string tags. Use labels to categorize and filter catalog definitions (for example, `production`, `engineering`, `finance`). Labels on a catalog definition are organizational only. Unlike labels on an Access Profile, they are not evaluated for catalog visibility, in any visibility mode. * **Custom Properties**: A key-value map for attaching arbitrary metadata to a catalog definition. Custom properties are available for reporting, integration, and automation purposes but do not affect catalog behavior directly. The properties offered on a catalog definition come from the tenant's custom attribute definitions, the same list that Access Profiles use. Edit that shared list from **Settings** > **Custom Attribute Definitions** on the **Catalog Definitions** page or the **Access Profiles** page. See [Defining custom attribute schemas](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md#defining-custom-attribute-schemas). *** ## Policy associations Each catalog definition is linked to two policies, both configured in the **Details** step: **Lifecycle Management Policy** (required) selects the Provisioning Policy that provides the execution context for fulfillment actions: * **Application** definitions execute the Provision Account action defined in the Provisioning Policy to create an account when one is needed * **Send REST Payload**, **Send XML Payload**, and **Send SQL Command** definitions execute the named grant and revoke actions of the matching type from the Provisioning Policy * **ServiceNow** and **Jira** definitions create tickets through a Veza Action (notification integration) of the matching type; the Provisioning Policy provides the execution context The Provisioning Policy must contain the actions referenced by the type-specific configuration fields (for example, the Provision Account Action to Run selected in an Application definition must exist on the associated Provisioning Policy). **Access Request Policy** (required) governs the approval workflow for requests made through this catalog definition. The policy's approval steps, JIT duration, and expiration rules apply to all requests for the catalog item. A catalog definition cannot be created without an Access Request Policy, and the field cannot be emptied on a later edit. See [Managing Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md). ### Approver categories that do not resolve for a catalog definition Two of the approver categories available to an Access Request Policy resolve their approvers from an Access Profile, or from the data source behind one. Neither source is present on every catalog definition. When a step names only such a category and no approver resolves, the request is not routed for approval: it moves to **Conflict Pending** instead. For a description of every category, see [Approver categories](/4yItIzMvkpAvMVFAamTf/features/access-request/approve-access.md#approver-categories). | Category | Behavior on a catalog definition | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Access Profile Owner** | Does not resolve, for any catalog definition type. A request submitted through a catalog definition carries no Access Profile, and the Access Profile is the only source this category reads. The **Allow approval on requests** option for this category is inert for the same reason. | | **App Owner** | Resolves only for **Application** catalog definitions, which name a data source. The ServiceNow, Jira, Send REST Payload, Send XML Payload, and Send SQL Command types carry no data source, so an App Owner step on a definition of those types resolves to nobody. | When you write an Access Request Policy for a catalog definition, give each step a second source, such as an additional category, a named user, or a Veza Group, or use a category that resolves independently of the Access Profile: Admin, Beneficiary Manager, or Dynamic. A request that has already reached Conflict Pending is recoverable: an administrator can reassign it to a different approver or cancel it, and a tenant setting can retry the routing on a schedule. For the recovery path and that setting, see [Beneficiary Manager approvals](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md#beneficiary-manager-approvals). *** ## Troubleshooting | Issue | Solution | | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Catalog definition not appearing in the Access Catalog | Verify the definition state is **Enabled**, then check the visibility rules. Confirm that the Provisioning Policy on the definition is the same policy that governs the requester's identity: a mismatch hides the item regardless of the visibility mode. | | Requester cannot see a catalog item | Check the visibility rules. For **Filter Strings** mode, verify that the requester's LCM identity attributes match at least one SCIM filter, and that at least one filter expression is defined. Neither **All** nor **Settings** restricts visibility, so an item in either mode that a requester cannot see points to the definition state or to a policy mismatch instead. | | Request approved but access not provisioned | For Application type, verify the LCM data source is connected and the referenced Provision Account action name exists on the Provisioning Policy. For Send REST Payload, Send XML Payload, and Send SQL Command, verify the grant action name matches an existing action of that type on the Provisioning Policy. | | Form fields not appearing on request form | Confirm form fields are configured in the type-specific configuration section of the catalog definition, not only at the top level. | | ServiceNow ticket not created | Verify the ServiceNow Integration references a valid, active ServiceNow Veza Action. Check the placeholder syntax in the headline and message body. | | Jira issue not created | Verify the Jira Integration references a valid Jira Veza Action. For revoke issues, confirm a Revoke Jira Integration is selected. Check the placeholder syntax in the headline and message body. | *** ## Related documentation * [Managing Catalog Items (Access Profiles)](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md): Configure Access Profiles as catalog items * [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md): Configure approval workflows * [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md): Global settings for catalog visibility and approvals * [Access Profiles in Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md): Guide to Access Profiles --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.