> 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-reviews/configuration/columns.md). # Customizing Default Columns ### Overview Columns in the review interface can be customized to rearrange, show, or hide certain attributes. Configuring default columns can improve overall readability, and offer reviewers valuable context for each row. Note that changes to columns made in the Veza UI will be saved to the browser. If a user has already customized a certification's columns, changes to the default settings will not apply. {% hint style="info" %} **Column Pinning and Reordering**: Reviewers can drag column headers to reorder them, or pin columns to keep them visible while scrolling. These customizations are saved to your browser and persist across sessions. {% endhint %} You can also change the default order in which rows appear. For example, you might want to show results in descending order by destination resource type. This can be useful to encourage reviewers to focus on particular rows earlier in the review. A set of global default columns and sort method applies to all reviews. You can also configure custom column orders for all reviews created for a specific configuration. There are two ways to set default columns: * **From the reviewer interface (UI)**: Administrators can set default columns and grouping directly from the review UI. This is the quickest way to configure defaults for a specific configuration. * **Using the API**: Use API calls to set defaults globally or per configuration. This approach is ideal for automation or bulk changes. ### Setting default columns from the UI Administrators can configure default columns for all reviewers using a specific configuration directly from the reviewer interface: 1. Open a review created from the target configuration in the reviewer interface. 2. Arrange columns to your preferred layout (show, hide, and reorder columns as needed). 3. Optionally, select a **Group By** option to set a default row grouping. 4. Click **Admin** > **Set Columns as Default**. The selected column layout and grouping option will be applied as the default for all future reviews created from this configuration. Existing reviews are not affected. {% hint style="info" %} The **Set Columns as Default** option saves both the column layout and any active row grouping selection. For more details on row grouping, see [Row Grouping for Access Reviews](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/row-grouping.md). {% endhint %} ### Setting default columns using the API Column customizations can also be configured using a private API call. This method is useful for setting global defaults, automating configuration, or making bulk changes across multiple configurations. By default, the customization applies to all reviews. Optionally, it will apply to all reviews created for a given `workflow_id` (corresponding to a review configuration in Veza). The following example sets per-workflow default columns, including source tags, custom properties, summary entities, and reviewers: ```json { "value": { "default_ordered_columns": [ "source.name", "source.department", "source.customprop_worker_status", "source.tags", "path_summary.name", "concrete_permissions", "destination.name", "destination.customprop_display_name", "reviewers" ] }, "workflow_id": "002063d2-7898-4183-b5fb-1192758fdec7" } ``` ### Sort order The default sort value is `source.type asc` for ascending order. You can default to descending order or sorting on another column by including an `order_by` value, for example: ```json { "value": { "default_ordered_columns": [...], "order_by": "source.name desc" } } ``` ### Column syntax Columns for entity attributes have the format: * `source.attribute_name`: Source entity attributes. * `destination.attribute_name`: Destination entity attributes. * `waypoint.attribute_name`: Attributes on the **Relationship** entity, if specified in the configuration. * `path_summary.name`: Shows **Summary Entities** from the configured scope. * `idp.attribute_name`: Attributes on the related IdP or HRIS user for a row, when the **Enrich** option is enabled for the configuration. Columns can also show row metadata: * `status` * `abstract_permissions` * `concrete_permissions` * `updated_at` * `notes` * `reviewers` * `decision` * `decision_by` * `decision_by_id` * `decision_by_name` * `decision_by_email` * `decision_at` * `marked_fixed_by_id` * `marked_fixed_by_name` * `marked_fixed_by_email` * `marked_fixed_at` * `signed_off_state` * `signed_off_by_id` * `signed_off_by_name` * `signed_off_by_email` * `signed_off_at` * `notification_status` * `automation_run_ids` * `no_decision_or_decision_by` * `is_signed_off` * `access_path_risk_score`: The consolidated access path risk score (0-100) for the row, shown when Access Intelligence is enabled. See [Access Path Risk Score](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/access-path-risk-score.md). * `risk_level`: The risk level tier (Critical, High, Medium, Low, or None) derived from the access path risk score. * `itsm_request_number`: Identifier of the related ticket in an ITSM system (for example, a ServiceNow incident number or a Jira issue key). * `itsm_request_status`: Current status of the related ITSM ticket, as a string. * `itsm_request_url`: Link to the related ITSM ticket. Rendered as a clickable URL in the reviewer interface. * `itsm_request_last_updated_at`: Timestamp of the most recent update to the ITSM fields on the row. ### ITSM request columns The four `itsm_request_*` columns let you surface ticket data from any ITSM system (ServiceNow, Jira, or other) directly in the reviewer interface, alongside the row being reviewed. The columns are system-agnostic: Veza stores the values as plain strings and does not parse or validate them against a specific ITSM provider. These columns are hidden by default. To make them visible to reviewers in a specific review, open the review and use **Admin** > **Manage Columns** to enable the `itsm_request_*` entries. To set them as default columns for every review created from a configuration, see [Setting default columns from the UI](#setting-default-columns-from-the-ui) above, or use a column customization API call. Veza does not populate the `itsm_request_*` fields automatically. They are written through an authenticated API call, typically by an external integration that looks up a ticket in your ITSM system and posts the result onto the matching review row. {% openapi src="/files/Aco9gj4MY2XoNiD4zIjr" path="/api/preview/awf/certifications/{certification\_id}/results:update\_itsm\_request\_info" method="post" %} [openapi.yaml](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-0d9d5973a247f0dc34943ed932d00eb6f5a41e3e%2Fopenapi.yaml?alt=media) {% endopenapi %} A single request can update between 1 and 100 results. Updates are partial: fields you omit are left unchanged, and setting a field to an empty string clears it. The `itsm_request_last_updated_at` timestamp is set automatically on every update. ```bash curl -X POST \ "$VEZA_URL/api/preview/awf/certifications/$CERTIFICATION_ID/results:update_itsm_request_info" \ -H "Authorization: Bearer $VEZA_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "updates": [ { "result_id": 12345, "itsm_request_number": "INC0012345", "itsm_request_status": "In Progress", "itsm_request_url": "https://example.service-now.com/nav_to.do?uri=incident.do?sys_id=abc123" } ] }' ``` A successful call returns `200 OK` with an empty body (`{}`). This endpoint requires the `modify_results_special_data` permission, granted to the `admin`, `access_reviews_admin`, and `operator` roles, and must be called from the **root team**. Each call is recorded in the Veza audit log as **Update ITSM Request Info**. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/columns.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.