business_service Mandatory on the task table
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2024 10:02 AM
I was asked to make a task if assigned to 4 certain groups the business_service field needs to be mandatory to close the task.
The type of task wasn't defined and over the last year those groups has used 15 different tasks of which 7 have the business_service field on the form. Those 7 task types are: Change Request, Incident, Incident Task, Problem, Defect, Enhancement, and Requested Item.
What is the simplest way to implement this while also keeping it maintainable when additional task type get utilized in the future?
I am getting turned around on if it should be implemented via a UI action, UI policy, or client script.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2024 04:53 AM
Hi @web48f
To implement a requirement where the `business_service` field needs to be mandatory for closing a task when it is assigned to one of four specific groups, and considering maintainability for future task types, you should use a combination of a Business Rule and UI Policies.
Here's why and how you would implement this:
Business Rule
A Business Rule can run on the server side when records are inserted, updated, or deleted, or when a query is performed. You can create a Business Rule that checks if the task is being closed and if it is assigned to one of the specified groups. If both conditions are met, the rule can enforce that the `business_service` field is not empty.
Here's a high-level overview of what the Business Rule would do:
1. When to run: Before the record is updated (before update).
2. Conditions: Check if the task's state is being changed to a "closed" state and if the `assignment_group` field is one of the specified groups.
3. Script: In the script, check if the `business_service` field is populated. If not, prevent the save operation and return an error message to the user.
UI Policies
UI Policies are client-side and can dynamically change form information on the fly without writing a single line of JavaScript. You can create UI Policies for the seven task types that currently have the `business_service` field on the form to make it mandatory based on the assignment group.
Here's what you would do with UI Policies:
1. UI Policy for each task type: Create a UI Policy for each of the seven task types where the `business_service` field is present.
2. Conditions: The condition for the UI Policy would be that the `assignment_group` is one of the specified groups.
3. Actions: If the condition is true, set the `business_service` field to mandatory.
Future Task Types
For future task types that may use the `business_service` field, you would simply need to create a new UI Policy for that task type. The Business Rule would already be in place to enforce the requirement on the server side, so you would only need to ensure that the client-side UI reflects the mandatory nature of the field.
Example Implementation
Here's a pseudo-code example of what the Business Rule script might look like:
(function executeRule(current, previous /*null when async*/) {
// Array of sys_ids for the four specific groups
var requiredGroups = ['group_sys_id_1', 'group_sys_id_2', 'group_sys_id_3', 'group_sys_id_4'];
// Check if the task is being closed and if the assignment group is one of the specified groups
if ((current.state == 'closed_state_value') && requiredGroups.indexOf(current.assignment_group.toString()) > -1) {
// Check if the business_service field is populated
if (current.business_service.nil()) {
// Prevent the save and return an error message
current.setAbortAction(true);
gs.addErrorMessage('The Business Service field must be populated to close this task.');
}
}
})(current, previous);
And for the UI Policy, you would configure it in the ServiceNow UI Policy module for each task type with the appropriate conditions and actions.
By using this combination of Business Rules and UI Policies, you ensure that the requirement is enforced both on the client side (for a good user experience) and on the server side (for data integrity), while also keeping the solution maintainable for future task types.
Please mark this response as correct or helpful if it assisted you with your question.