Advanced Settings

Advanced settings can be configured and updated at three levels:

• Application level: All profiles of an onboarded application are configured for advanced settings.
• Profile and policy level: A particular profile or a profile policy is configured for advanced settings. Profile level settings apply to all policies of that profile.
• Resource profile or policy level: A resource profile or profile policy is configured for advanced settings. Resource profile level settings apply to all policies of that resource profile. 

These settings are inherited from the application to profile to policy.

To configure the advanced settings, follow these steps:

1. Login to Britive with administrator privileges.
   • Application level:
     1. Click on Admin -> Application and Access Profile Management.
     2. Select the application and click on the Manage icon.
     3. Click on the Advanced Settings from the navigation menu
     4. Click on the Edit to update the default values.
     5. Update the values using Advanced Settings.
   • Profile: Select a particular profile of an onboarded application and update these values. If advanced settings at the profile level are updated, they take precedence over settings at the application level. 
     • For profile-level advanced settings, see Managing Britive Profiles.
     • For profile policy level advanced settings, see Managing Britive Profiles.
   • Resource profile setting:
     • For the resource profile level advanced settings, see Resource Profile Management.
     • For the resource profile policy level advanced settings, see Resource Profile Management.

Advanced Settings

Configure the following advanced settings:

• Justification Settings: 
  1. Reset:
     1. For application-level settings: Reset to default
     2. For profile-level settings: Reset to application settings
     3. For policy-level settings: Reset to profile settings
  2. Justification Required at Checkout: Select if justification is required for a checkout operation. This setting does not apply to approvals, a justification is always required for approvals.
  3. Regular Expression for Justification: Click View Expression to view or edit the regular expression. This setting is independent of the Justification Required at Checkout. If enabled, it applies to the justifications for the checkout and the approval operations, otherwise applies only to the approval operations.
     1. Enter the regular expression in the text area and test string. A regular expression can be set to accept justification in a specific format only. The system only accepts justification that matches the regular expression. If this value is kept blank, the user can use any format for the justification.
     2. Click on Validate Expression to validate the regular expression. You can save the regular expression only after successful validation.
• ITSM Settings:
  1. Reset:
     1. For application-level settings: Reset to default
     2. For profile-level settings: Reset to application settings
     3. For policy-level settings: Reset to profile settings
  2. Enable ITSM integration for Checkout and Approval Requests: If this option is enabled, the ITSM (Jira and ServiceNow) ticket number must be provided during checkout and approval operations. Once enabled, the other settings need to be configured. The settings are used to specify what ticket the requester can use during the checkout/approval operation.
     
  3. Select ITSM Connection: ITSM connections must be created before updating these settings. For more information, see Creating and Managing ITSM Connections. The administrator can select an ITSM connection from the list of available connections. The following options are displayed based on the type of connection (Jira or ServiceNow)
     • Jira: Select the Issue and click Add Filter to add filter criteria for the issue.
     • ServiceNow: Select whether it is an Incident or Change Request. 
  4. Click the Add Filter button to add a new filter for ITSM connection type. Enter the following in the Filter Criteria window:
     • Enter Filter Criteria in the JSON format in the text area. For more information about filter criteria, see 
       • Filter Criteria for Jira Connections
       • Filter Criteria for ServiceNow Connections 
     • Enter the Ticket ID to validate JSON. 
     • Enter Email/Username only if {email}/{username} is used in the filter. You can save the filter criteria only when the validation is successful. For more information about validating filter criteria, see Validating Filter Criteria. 

Filter Criteria for Jira Connections

• For Jira projects with restrictive access, a Browse Projects permission must be granted to the service account or user. For more information about project permissions in Jira, see Managing Project Permissions.
• The accepted JSON key is jql and the value is a JQL string. The JQL string is as per the Jira JQL documentation. For more information see the following JQL documentation:
• 
  
  • Get started with advanced search in Jira 
  • Use advanced search with Jira Query Language (JQL) 
• The JQL string can be prepared and tested in the Jira console, the same value can be used as a value for jql. For more information, see Advanced Search in Jira cloud. Use Switch between Basic and JQL option: Select Basic to define a filter and switch to JQL to get the JQL value."
• Single quotes must be used instead of double quotes in case there are any in the JQL. Alternatively, escape characters can be used in the JSON.
• The currentUser() in the JQL string needs to be replaced with {username} or {email} variables as per the requirement. For example:
  project = 'Test' AND assignee = currentUser() needs to be updated as project = 'Test' AND assignee = '{email}'
• The UI shows and uses the below default filter while configuring the filter criteria. This allows the requesters to use the tickets assigned to only them.
  JSONJSON

  {
  "jql": "assignee = \"{email}\""
  }

• The blank value for the JQL allows the user/requester to select any valid ticket number.
  JSONJSON

  {
  "jql": ""
  }

Examples

• Allows the requester to select the issues of the specific project where the assignee is the requester. 
  JSONJSON

  {
     "jql": "project = TEST AND assignee = '{email}'"
  }

• Allows the requester to select the issues of type "Task" created within the last 7 days.
  JSONJSON

  {
     "jql": "type = 'Task' AND created >= -7d"
  }

Filter criteria for ServiceNow type of connections

• The accepted JSON key is sysparm_query and the value is a sysparm_query string.
• The sysparm_query string is as per ServiceNow documentation for the sysparm_query value. For more information about the description of the sysparm_query query parameter of GET /now/table/{tableName} API, see Table API.
• The sysparm_query value can be captured from the ServiceNow web console. For more information about getting query value, see Filters and Breadcrumbs ServiceNow documentation.
• The incidents or change requests list can be filtered on the ServiceNow web console by providing the conditions. The  sysparm_query value can be retrieved by right-clicking on the filter and selecting Copy query.
• The assigned_to=<user_id> value in the filter needs to be replaced with {username} or {email} as per the requirement. For example: ServiceNow Filter active=true^assigned_to=5137153cc611227c000bbd1bd8cd2007 should be updated as follows for using it in the filter: active=true^assigned_to.email={email} or active=true^assigned_to.user_name={username}
• The UI shows and uses the below default filter while configuring the filter criteria. This allows the requester to use the tickets (incident or change request) that are assigned to only them.
  JSONJSON

  {
     "sysparm_query": "assigned_to.email={email}"
  }

  
  
• This can be updated as follows to match the Britive user's username with the ServiceNow assignments instead of email.
  JSONJSON

  {
     "sysparm_query": "assigned_to.user_name={username}"
  }

• The blank value for the sysparm_query: Allows the user/requester to select any valid ticket number.
  JSONJSON

  {
     "sysparm_query": ""
  }

Examples 

• Allows the requester to select the active incidents assigned to the requester and opened within the last 7 days.
  JSONJSON

  {
     "sysparm_query":
     "active=true^assigned_to.email={email}^opened_at>=javascript:gs.beginningOfLast7Days()"
  }

  
  
• Allows the requester to select the approved changes with the start date in the given date range.
  JSONJSON

  {
    "sysparm_query":  "approval=approved^expected_startBETWEENjavascript:gs.dateGenerate('2024-09-29','00:00:00')@javascript:gs.dateGenerate('2024-10-07','23:59:59')"
  }

Validating the Filter Criteria

• The filter criteria must be validated before saving. It does syntactical validation and verifies that the provided Ticket ID matches the filter criteria. This verifies what ticket the requester can use to submit the checkout/approval requests.
• If {username} or {email} variables are used in the filter, it loads the default values of the currently logged-in administrator. The administrator can change these values if needed for the validation.
• The filter is validated by calling the ITSM APIs against the selected ITSM connection. The variable values are replaced with the provided values. These variables are replaced with the values of the requester (logged-in user) while validating the ticket during the checkout/approval. 
• If the validation is successful, it shows the basic ticket details.
• In the case of ServiceNow filter syntactical validation, the additional settings at ServiceNow need to be performed. Otherwise, it skips the syntactical validation and ignores the invalid part. It is the administrator's responsibility to use the filter value cautiously in the absence of this setting. To configure this setting, see Configuring ServiceNow Setting for Filter Syntactical Validation.