# Creating SoD Detection Queries

### Overview

Use the *Separation of Duties* query builder to detect SoD conflicts, and save searches to create customized SoD rulesets in Veza. The SoD query interface provides a streamlined version of the Access Intelligence Query Builder, with special support for defining SoD violations with `AND` and `OR` statements.

For each query, you will need to:

* Define the type of user the rule applies to (either an identity provider identity or a local user account).
* Identify the conflicting roles or permissions across one or more target applications by specifying each destination entity type, and the roles or permissions that represent an SoD conflict.

Click *Run* to view the current results or *Open in Query Builder* for more details. Click *Edit and Save* to assign a risk level, and add risk explanation and remediation details. You can optionally add rules, schedule exports, or add the query to dashboards while saving it.

This document includes steps for [Using the SoD Query Builder](#using-the-sod-query-builder). See [Example SoD Queries](/4yItIzMvkpAvMVFAamTf/features/separation-of-duties/sod-examples.md) for different types of SoD risks.

### Using the SoD Query Builder

Separation of Duties queries typically search for users with relationships to two or more sets of conflicting roles/permissions – but might be defined in terms of a user's effective access to data resources, local user accounts, and/or role or group assignments. The search can include any [Entity Type](/4yItIzMvkpAvMVFAamTf/features/insights/entities-overview.md) from integrations added to Veza.

To define a conflict, use the builder to create groups of access conditions using logical AND or OR operators. Each condition describes a relationship between the source and destination entity type:

```txt
User RELATES TO
[(Access Condition 1) OR (Access Condition 2) or (Access Condition 3)]
AND
[(Access Condition 3) OR (Access Condition 4)]
AND
(Access Condition 5)
```

For example:

* If a user with Role A, Role B, or Role C would create conflict if they were also assigned Role D and Role E:
  * The query conditions would be `(Role A OR Role B OR Role C) AND (Role D OR Role E)`.
* If a user is in conflict when they can delete AWS S3 Buckets and also access Salesforce:
  * The query conditions would be `(Any Salesforce User) AND (Any S3 Bucket with s3:DeleteBucket permission)`

You can add many groups of conditions to the query, and each condition can apply to a different destination application.

To create an SoD query:

1. Go to the *Separation of Duties* page.
2. Click *+ New SoD Query*
3. From the *Select User Type* dropdown menu, select the user type the SoD risk applies to, for example, *Azure AD User* or *Snowflake Local User*.
4. Use the condition builder to define the relationships that constitute a violation of separation of duties.

   For each condition, select a related entity type (e.g., Oracle Fusion Role, Workday Domain Security, S3 Bucket), and optionally a specific entity of that type (e.g., a role, permission, or local user):

   * Add conditions by clicking the *+ And* button and *+ Or* buttons to describe the SoD violation.
   * For each condition, choose the related *Entity Type* (e.g., “Workday Domain Security Policy”) and expand the *Select Entity Name* dropdown to search for a single entity (e.g., “Process: Expense Reports”).

     When an optional name is not provided, the condition applies to any entity of the chosen type. A condition can describe a single role assignment or table, or access to ANY roles or resources of the chosen type.
   * For some entities, such as AWS S3 Buckets or database tables, you can choose a *Permission Type* to filter by system-level permissions, or filter by effective permissions the user has on the resource.
5. Review the query logic: The *query output* section below the conditions describes the logic for identifying the SoD violation. Refer to this description to verify that the query correctly represents the rule’s intent.
6. Click *Run* to preview the potential violations based on current data.
7. Customize the display output for more information about the results. You can focus on the most important attributes by using the column selection menu to hide or show columns.
8. Click *Edit and Save* to finalize your changes. While saving the query, you can:
   * Give it a name, description, label, and risk level, and set whether it is public or private.
     1. Use the query name to briefly identify the system and risk (e.g. `Oracle: Cash and Accounts Payable`)
     2. Add a risk level to enable the Risk Remediation and Risk Explanation fields for additional logging and notes.
   * Add optional [Alert Rules](/4yItIzMvkpAvMVFAamTf/features/insights/rules-and-alerts.md) by defining conditions, and actions to trigger email notifications or Veza Actions at different levels of severity.
     * You can create Alert Rules to trigger [on-demand access reviews](/4yItIzMvkpAvMVFAamTf/features/separation-of-duties/sod-access-reviews.md#on-demand-access-reviews) when new conflicts are detected.
   * Add the query to [Dashboards](/4yItIzMvkpAvMVFAamTf/features/insights/dashboards.md), and choose the dashboard sections the query will appear in.
   * Schedule export of the results to an integrated [Snowflake database](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/export-to-snowflake.md) or email recipient.
   * After saving an SoD query, you can create a [1-Step Access Review](/4yItIzMvkpAvMVFAamTf/features/separation-of-duties/sod-access-reviews.md#1-step-access-reviews) directly from the query using the Actions menu. This will create a new review using the latest results.
   * To enable recurring reviews on a schedule, save a review configuration using the SoD query builder, and [Create a Schedule](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/schedule-access-review.md) for the configuration.


---

# Agent Instructions: 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:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/separation-of-duties/sod-queries.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.