# Configure Safety Views in Safety Workbench Safety views determine the reporting data for a _Workbench Report_. You can also use safety views to preconfigure _Workbench Report_ parameters such as filters and field grouping. These parameters are applied to a _Workbench Report_ when a user selects the safety view on the _Workbench Report_. Workbench includes the following safety views: * **Principal Views**: Contain the largest collection of data and preconfigured parameters. For example, a _Principal View_ might include data for all _Case_ versions. Vault derives all _Workbench Views_ from a _Principal View_. * **Supporting Views**: Provisioned by your Veeva Representative to support _Principal Views_. This view type provides a subset of data for _Principal Views_ to use in report generation, for example, expectedness information. * **Workbench Views**: Contain a subset of data from a specified _Principal View_ and provide a more narrow and specific report analysis. * **Dynamic Views**: Contain commonly used Safety fields that users can add to _Workbench Reports_ for ad-hoc analysis. You can associate these views with a _Principal View_ using a _Workbench View Dynamic Join_. Before you can use these views, you must perform the necessary _configuration_.

Note: Do not edit a safety view if a Workbench Report is using it. Any changes you make to the safety view will not be reflected in Workbench Reports referencing this safety view.

Your Safety Workbench Vault includes standard safety views that cannot be edited. You can copy a standard view and then modify the parameters of the custom view. For more information about these views, contact your Veeva Representative. The following sections in this article describe the different sections of a safety view and how to complete them.

## Create and Access Safety Views {#create-and-access-safety-views} To create a safety view: 1. Navigate to **Business Admin > Objects > Workbench Views**. 2. Select **Create**. 3. In the _Create Workbench View_ window, specify the type of view you want to create and then select **Continue**. 4. Complete the following information about the safety view in the _Details_ section: * **Name**: Enter a **Name** for the safety view. * **API Name**: Enter an **API Name** for the safety view. The API Name cannot include spaces and must end in `__c`. * **Description**: Enter a **Description** for the safety view. * **View Tag**: Select a tag from the picklist to organize this safety view. Add values to the _Workbench View Tag_ picklist as needed. * {: #follow-view-sort-order-checkbox} **Sortable by Row Number**: Select **Yes** to allow users to follow the sort order configured in this safety view's SQL. Contact your Veeva Representative to provide the appropriate input. Otherwise, select **No**. * **Use Total Row**: This field appears for _Workbench View_ types only. Select this checkbox to display a _Grand Total_ row on _Workbench Dashboards_ using this view. Then, contact your Veeva Representative to provide the appropriate SQL input.

Note: You cannot save Supporting Views. This view type is only for standard views provisioned by your Veeva Representative.

## Dependent Views {#dependent-views} When creating a new _Workbench View_, this section appears only after saving. A _Workbench View_ is always dependent on another safety view, meaning it derives its data and configuration parameters from the specified safety view. The safety view on which the _Workbench View_ is dependent is known as a dependent view. A dependent view can be a _Principal View_ or another _Workbench View_. As _Principal Views_ are the basis for _Workbench Views_ to add additional filters, _Principal Views_ do not have any dependent views. The safety view hierarchy starts with a _Principal View_, which leads into subsequent _Workbench Views_ with a more specific data set. These _Workbench Views_ can lead into other _Workbench Views_ with even more specialized data sets.

Although a _Workbench View_ may not always include a _Principal View_ in the _Dependent Views_ section, a _Workbench View_ must ultimately be associated with one (1) unique _Principal View_ through other dependent views. In the above example, _Workbench View_ A.1/A.2 is not directly associated with the _Principal View_ but is associated with it through _Workbench View_ A.

Note: If a dependent view is not associated with any or is associated with more than one (1) Principal View, you cannot add filters on the safety view or the Workbench Report.

### Create a Dependent View {#create-a-dependent-view} To add a dependent view: 1. In the _Dependent Views_ section of the safety view, select **Create**. 2. In the _Create Workbench View Dependent_ window, select a _Dependent View_. 3. Select **Save** or **Save + Create** to add another dependent view. **Result** Vault adds the selected dependent view(s) to the _Dependent Views_ section and generates a name for each. The current view is now dependent on these selected safety views. ## SQL Editor {#sql-editor} SQL offers elaborate queries for parsing through data. You or your Veeva Representative can provide and input queries in the _SQL Editor_ section. The queries are based on Amazon Redshift SQL, which is a subset of PostgreSQL 9.x. For more information on the available SQL functions, refer to Amazon Redshift and PostgreSQL. You can enlarge the _SQL Editor_ section by selecting the **Full Screen** (

) icon. The SQL query provides references for the fields specified in the safety view's [_Workbench View Columns_][1] section. If you [run a preview][2] of the safety view without any _Workbench View Columns_, all fields returned by the SQL query will be displayed in the preview. The safety view can also leverage another safety view by referencing the safety view's _API Name_ in the _SQL Editor_ section, for example, `select * from ${safety_view_api_name__c}`. You must also [create a dependent view][3] for the safety view you are referencing. Consider the following SQL limitations and restrictions: * Vault does not perform timeout checks when running SQL. Long-running queries will be terminated by Amazon Redshift. Related performance issues are identified through logged server errors. * The query size limit is 32,000 characters. ### SQL Editor Search Panel {#search-panel} Before you can access _SQL Editor_ keyboard shortcuts and the search panel, you must configure _SQL Editor_ enhancements. After performing the necessary configuration, you can open the _SQL Editor_ search panel by using the **Ctrl + f** or **Cmd + f** keyboard shortcut, as applicable. Using the search panel, you can find or replace specific texts and syntax elements. The panel also includes the following settings: * _Match case_: Select this checkbox to make your keyword case sensitive. * _Regexp_: Select this checkbox to use regular expressions. * _By word_: Select this checkbox to search for whole words only. For example, if your keyword is `filter`, Vault excludes elements such as `filterview`. ## Workbench View Objects {#workbench-view-objects} The [_Workbench View Column_][1] and the _Workbench View Object_ sections both influence the _Workbench Report_ layout. Where the _Workbench View Columns_ define the fields users can add to the layout, the _Workbench View Objects_ specify the fields you can group by on the _Workbench Report_ layout. If you do not add _Workbench View Objects_ to this safety view, grouping will not be available for _Workbench Reports_ using this view. The _Workbench View Objects_ section consists of fields and one (1) parent object. The fields in this section correspond to the fields in the _Workbench View Columns_ section. ### Create Workbench View Objects {#create-workbench-view-objects} To create _Workbench View Objects_: 1. In the _Workbench View Objects_ section, select **Create**. 2. In the _Create Workbench View Object_ window, complete the following information: * **Name**: Enter the name of the field. * **API Name**: Enter the API name of the field. This value must end in `__c`. * **Parent Object**: Select the parent object from the drop-down or use the **Advanced Search** (

) icon to use filters and refine your search. Leave this field blank if you are creating the parent object. 3. Select **Save**. 4. Repeat the steps above to add additional fields. 5. (Optional) To delete a field, select the **Actions** menu next to the field and then select **Delete**. ### Grouping Criteria {#grouping-criteria} Users can group fields on the _Workbench Report_ layout by the fields you add to the _Workbench View Objects_ section if the following criteria are met: * In the _Workbench View Objects_ section, the field the user wants to group by is assigned to the [parent object][4]. * In the _Workbench View Columns_ section: * For the field the user wants to group by, there is a corresponding field in the _Workbench View Column_ section. * The field must be of the _Object_ or _Picklist_ column type. * The field's _Workbench View Object_ field must be set to the [parent object][4]. ## Workbench View Columns {#workbench-view-columns} When creating a new safety view, this section appears only after saving. The configuration you perform in a safety view's _Workbench View Columns_ section determines the fields you can add to the _Workbench Report_ layout. Adding fields to the _Workbench View Columns_ also makes them available for _Workbench Report_ filters, if you are creating a _Principal View_. The _Workbench View Columns_ are also required for the [safety view's SQL][5] to run successfully. Supported field types include: * _Text_ * _Date_ * _DateTime_ * _Number_ * _Yes/No_ * _Object_ * _Picklist_ * _Multi-Value Picklist_ * _MedDRA_ ### Create Workbench View Columns {#create-workbench-view-columns} To create the _Workbench View Columns_: 1. In the _Workbench View Columns_ section, select **Create**. 2. In the _Create Workbench View Column_ window, complete the following fields: * **Name**: Enter the name of the _Workbench View Column_. This value appears to users as a field in the _Workbench Report_ layout. * **API Name**: Enter the API name of the _Workbench View Column_. This value must match the name of the column returned by the [SQL query][5]. * **Column Type**: Select a field type option from the drop-down. For _Object_ and _MedDRA_ types with a specified _Safety Object Reference_, Vault displays the record name instead of the ID for _Workbench Dashboards_ and _Workbench Report_ outputs.

Note: Displaying record names instead of IDs may result in slower performance when the SQL query runs. If your safety view has many Object and MedDRA type view columns, we recommend testing the view for performance before using it in reports and dashboards.

* Optional: **Safety Object Reference**: The _Safety Object Reference_ and _Safety Object Constraint_ fields allow you to restrict the values that appear when filtering on this object. For example, you can restrict the _Controlled Vocabulary_ object to display only _Drug Roles_. Enter the API name of the object associated with this view column field. * Optional: **Safety Object Constraint**: The _Safety Object Reference_ and _Safety Object Constraint_ fields allow you to restrict the values that appear when filtering on this object. For example, you can restrict the _Controlled Vocabulary_ object to display only _Drug Roles_. Enter VQL to configure a reference constraint to restrict the object values. * {: #case-version-key} **Case Version Key**: This field enables using _Case_ series for _Workbench Reports_. If you do not see this field, you must first enable _Case_ series. * For the **id** view column field, select **Yes**. You must set this field on the safety view's dependent _Principal View_ and, optionally, on the safety view. When this field is set only on the _Principal View_, Vault applies the _Principal View_'s parameters to the _Case_ series to generate the report output. When this field is set on both the safety view and the _Principal View_, Vault uses the safety view's parameters. * **MedDRA Hierarchy**: For view columns of the _MedDRA_ column type, Vault sets this field to _LLT_ by default. You cannot edit this field 3. Select **Save**. 4. The _Primary Key_ field applies to safety views with _Workbench View Objects_. Each _Workbench View Object_ must have one _Workbench View Column_ with the _Primary Key_ column set to **Yes** and can have unlimited _Workbench View Columns_ with the _Primary Key_ column set to **No**. 5. Repeat the steps above to add additional columns. 6. (Optional) To delete a field, select the **Actions** menu next to the field and then select **Delete**. ## Create Dynamic View Joins For _Principal Views_, use _Workbench View Dynamic Joins_ to associate the _Principal View_ with a _Dynamic View_. ## Workbench View Parameters {#workbench-view-parameters} When users apply filters to _Workbench Reports_, the data set can change before the safety view SQL queries them. Using _Workbench View Parameters_, users can enter filter values on the _Workbench Report_ that can then be referenced directly by the safety view's SQL. _Workbench View Parameters_ may appear as optional or required filters in the _Filters_ section under the _Criteria_ subsection.

Note: You cannot add Workbench View Parameters to a Principal View or a Supporting View.

### Create or Add Workbench View Parameters {#create-or-add-workbench-view-parameters} To create _Workbench View Parameters_: 1. In the _Workbench View Parameters_ section, select **Add**. 2. In the _Search: Workbench View Parameter_ dialog: 1. Filter for and select existing parameters. 2. Select **Create.** Complete the following information and then select **Save** or **Save + Create** to save the record and create another: * **Name**: Enter a name for the _Workbench View Parameter_. * **Description**: Enter a description for the _Workbench View Parameter_. * **API Name**: Enter an API name for the _Workbench View Parameter_ ending in `__c`. * **Optional**: Select **Yes** if the parameter is not required for the report to run. Leave this field as **No** if the parameter is required. * **Column Type**: Select a field type option from the drop-down. * **Allow user to select multiple values**: If the _Column Type_ is either _Picklist_ or _Object_, you may select **Yes** to allow users to select multiple values for this _Workbench View Parameter_. Otherwise, select **No**. * **Picklist Reference**: This field allows you to restrict the values that users may enter. Enter the _API Name_ of the desired picklist. * **Safety Object Constraint**: The _Safety Object Reference_ and _Safety Object Constraint_ fields allow you to restrict the values that appear when filtering on this object, for example, restricting the _Controlled Vocabulary_ object to display only _Drug Roles_. Enter the _API Name_ of the object associated with this view column field. * **Safety Object Reference**: The _Safety Object Reference_ and _Safety Object Constraint_ fields allow you to restrict the values that appear when filtering on this object, for example, restricting the _Controlled Vocabulary_ object to display only _Drug Roles_. Enter VQL to configure a reference constraint to restrict the object values. 3. Select **OK**. After you add a _Workbench View Parameter_ to a safety view, _Workbench Reports_, _Workbench Dashboards_, and _Workbench Report Sets_ that use this safety view will require the user to enter a criteria value. This criteria value is used directly in the [SQL query][5] by entering the `${parameter.api_name}` token. For example, a parameter of the _Yes/No_ column type is created to exclude follow-up _Cases_ and it is named `exclude_followup__c`. In the _SQL Editor_, this parameter would be referenced as:

CASE WHEN ${parameter.exclude_followup__c} <SQL> 

${parameter.exclude_followup__c} THEN <SQL>

### Update Workbench View Parameters {#update-workbench-view-parameters} You can edit custom (`__c`) _Workbench View Parameters_: 1. Navigate to **Business Admin > Objects > Workbench View Parameters > [Workbench View Parameter]**. 2. Select **Edit**. 3. Update information as needed. 4. Select **Save**. ## Filters {#filters} You can configure filters in the _Filters_ section of the safety view. Filters you add to the safety view can also be used to generate an output when users run a _Workbench Report_. You can add safety view filters only if the [_Workbench View Columns_][1] section is populated. To add safety view filters on a _Workbench View_, you must first define _Workbench View Columns_ on the associated _Principal View_. For more information, see Add Safety View Filters in Safety Workbench. ## Run Preview {#run-preview} You can generate a preview of the safety view by selecting **Run** in the _Run Preview_ section. After you run the preview, Vault executes the SQL for this safety view and returns a list of up to 100 records. Optionally, you can select the column header to sort the records returned by the run preview. The preview output also depends on whether you select the _Use View Columns_ checkbox: * If you leave the checkbox selected: Vault returns fields that are defined by the [SQL][5] and have a corresponding [_Workbench View Column_][1]. The output is displayed in a table format based on the _Workbench View Columns_'s column type. * If you clear the checkbox: Vault returns all fields specified in the SQL, regardless of whether the safety view contains _Workbench View Columns_. Clearing the _Use View Columns_ checkbox allows you to preview your SQL changes quickly without having to configure _Workbench View Columns_. If the SQL is invalid, Vault returns an error. _Run Preview_ also times out after 300 seconds. Vault inactivates the _Run_ button when you add a [_Workbench View Parameter_][6] to the safety view, as _Workbench View Parameters_ require user input to obtain data.

Note: As Run Preview is optimized for speed and not accuracy, it’s best practice to test your safety view using a report or dashboard. Depending on your SQL, some data may be impacted or may not appear in the preview. For example, when executing SQL with a Group by value on a large dataset, Run Preview may limit the amount of data being aggregated.

[1]: #workbench-view-columns [2]: #run-preview [3]: #create-a-dependent-view [4]: #parent-object [5]: #sql-editor [6]: #workbench-view-parameters