Task and Workflows

[Ganesh Pardhe]

Hello Developers,

This below article is about some practice about Task and Workflows.

Task and Workflows

The Task[task] table is a special table in ServiceNow that holds records where work is done. Like any base system table that's meant to be extended, the task table contains a number of fields relating to task records and the work that's done in them. For example, the need to assign a task is almost universal, so the Assigned to [assigned_to] field exists on the base task table.

A base table is a table in ServiceNow that is extended by other tables, but which does not, itself, extend any other table.

The task table (or rather, tables that extend the task table) also include task-specific functionality built-in, such as work notes and an activity log, workflow integration, SLAs, and so on!

In this chapter, we'll learn about the following:

• The Task [task] table and important fields on it
• Extending the task table
• How to add fields to the task table (and when not to!)
• Field dictionary overrides
• The Task Interceptor
• Journal fields and the activity formatter
• Approvals and workflows
• Assignment rules
• Inactivity monitors
• Visual task boards
• Major task-related pitfalls to avoid
• SLAs (Service-Level Agreements) and SLA Timers

Important task fields

The task table, like any table, consists of table columns (fields) that can store data for each record. In particular, the task table has several fields which are supremely useful for nearly any record that could be used to track work in ServiceNow. Below are some of those fields, and a description of their purpose. These fields may or may not be shown on the form or the list of any task-extended table, but all of them exist on all tables that extend the Task [task] table.

Active

Active is a Boolean field. This means that it stores a true/false value, and displays on the form as a check-box. This field is often controlled by a business rule. A business rule is a server-side script that runs in response to certain events on a record. In this case, the event that triggers the State field is usually what determines whether the Active field should be set to true or false. The Active field is a good general indicator as to whether a state is... well, active!

The Active field is also sometimes used to determine whether a user should have access to modify a ticket or not. For example, for reporting accuracy, many companies do not want Incident records modified after they've been closed. Instead, a service desk agent or user should submit a new incident record. For this reason, many companies create an ACL (Access Control List, or Security Rule) on certain task tables to prevent modification by anyone except admins or managers once a task is deactivated (after it's closed).

Additional comments and work notes

The Additional comments and Work notes fields are the two Journal fields that are present by default on the Task [task] table (and thus, on all tables that extend the task table):

By default, the Work notes field can be updated only by users with the itil role, whereas the Additional comments field can be updated by any users. This creates a separation between notes that are meant to communicate back and forth with the customer, versus notes meant to log work or serve as technical information that shouldn't necessarily be exposed to the user.

More on Journal fields in the next section.

Assigned to and Assignment group

The Assigned to [assigned_to] field is a reference field type that points to the Users [sys_user] table. This field is generally used to designate a user to work on, or be responsible for the task. By default, this field has a reference qualifier (role=itil) set on its dictionary record that prevents any non-itil user from being assigned to a task. You can override this reference qualifier on tables that extend task though, as the Project Task and Service Order tables do, if you have the relevant plugins installed.

The Assignment group [assignment_group] field serves pretty much the same purpose. The reason for having both, is that a workflow might automatically assign a certain type of task ticket to a group, but you would not want to hard-code a specific user to be responsible for such tasks (what if that user left the company?), so you'll generally assign a ticket to a group, and have a BA, manager, or the itil users themselves assign tickets to individual IT workers.

By default, the Assigned to field is also set as Dependent on the Assignment group field. The result of this, is that only users who are in the assignment group can be chosen in the Assigned to field.

Created, Created by, Updated, and Updated by

These fields are quite similar, but are used too frequently that we'd be remiss not to discuss them.

The Created [sys_created_on] field contains the date and time of the creation of this task record.

The Created by [sys_created_by] field tells you who created the record.

Updated [sys_updated_on] and Updated by [sys_updated_by] are the same as their corresponding Created fields, except that they are continually updated as the record is updated, to show when the most recent update was, and who made it. These fields can be exceptionally useful for reporting and determining who's working on what tickets, and whether any tickets are slipping through the cracks.

Description and Short description

As their names imply, Short description [short_description] is a field for a short description of the task (with a default character limit of 255), whereas Description [description] field is for a more comprehensive explanation of the issue, often including specific instructions. Description has a default character limit of 4,000 characters.

The default size of a text field on the form is determined by its character limit. If a field allows the input of 256 characters or more, it is displayed as a larger, multi-line input box, whereas 255 or fewer characters means it'll display as a single-line input box.

Number

The Number [number] field contains an identifier that is generally intended to be unique, and is the default display value for task records. As you may recall, the display value is the value that represents the record when referencing it from elsewhere in the system, such as a reference field on another record. When creating a task type, you would generally select the number prefix (such as INC for Incident records).

State

The current status of a task record is indicated by the State [state] field. This field may be driven by workflow, business rules, or may be manually selected by an ITIL user (usually the user in the Assigned to field).

Journals and the Activity formatter

Journal fields technically don't store data in the table that the Journal field is on, but instead, create entries in the Journal Entries [sys_journal_field]table. These journal entries, along with other values corresponding to changes to audited fields from the Sys Audits [sys_audit], History [sys_history_line], and Record History[sys_history_set]tables, are displayed in the Activity formatter.

Journal fields only work on audited tables. Adding such a field will modify a non-audited table's System Dictionary entry so that it becomes audited.

There are three types of Journal fields that you can add to your forms: journal_list, journal, and journal_input.

Journal_list fields don't actually store data, but are used more like formatters. If you visit the dictionary record for a journal_list field (such as when you're creating it), you can navigate to the Advanced view using the Advanced view UI action on the dictionary form. On the Advanced view, you'll see a Dependent Field form section with a Use dependent field check-box in it. Checking this box will reveal the Dependent on field field. Using this method to set the journal_list field dependent on a journal or journal_input field, will cause data entered into the selected field(s) to be shown in the journal_list field.

Examples of Journal fields include the Work notes and Additional comments fields. As you can see in the default Incident form, these fields are combined, and display the list of combined Journal Input fields beneath them. If you have one of these fields on your form, then all other Journal fields will be combined with them into one segment which you can expand to display the fields separately, or select from the select-box below the Journal field(s) to choose which field your input is directed into.

Just like journal fields, journal_input fields allow you to enter notes that can be displayed either in the Activity formatter (if that particular journal input field is tracked), or in a journal_list field. The difference is that if you have only journal_input fields on your form, the inputs will not be combined in a drop-down beneath the input boxes as with Journal fields:

Unfortunately, the Activity formatter is a protected object in ServiceNow, and cannot be directly modified. However, you can customize which tables are audited, and which fields show up in the activity log when modified. Start by clicking the filter icon to the right of the Activity formatter, scroll to the bottom of the list, and click on Configure available fields as shown in the following screenshot:

On the next page, simply double-click, or click to select a field and then click the right-arrow to move it over from the Available column, to the Selected column as shown in the following screenshot:

You'll notice that not only future changes are present, but also any previous changes made to the newly selected field will show up in the activity log!

If your table is audited (which you can determine from the table's record in the System Dictionary), changes are always being tracked in the background. This means that if you make a change to a field that isn't tracked in the activity log (for example, the Category field on the Incident table), and then add it to be tracked in the activity log, any historical activity within that field will be displayed as well.

Extending the task table

The task table is an incredibly powerful base table, yet interestingly, no records should ever be created directly on the task table. Instead, task records are created on child tables; tables that extend the task table. In fact, if you attempt to create a new task directly from the task table, you'll find that you're redirected to the task interceptor instead, which disambiguates which sort of task you'd like to create:

To extend the task table and inherit any relevant fields and business logic, start by navigating to System Definition | Tables. On the list of tables, click New from the top-left.

Since we've already created the Virtual War Rooms table, let's create a sub-table that also extends the task table. We'll call it War Room Task, so enter that into the Label field of the New table form, then press Tab. The Name field will auto-populate with an appropriate name: u_war_room_task.

In the Add module to menu field, select the Virtual War Room application menu we created earlier, and then click the magnifying glass icon next to the Extends table field input box. Search for the text task, and make sure to select the correct Task [task] table as shown in the following screenshot:

Right-click on the New Table form header, and click Save. This will display the table columns that were inherited from the system, and from the task table.

Next, head over to the Controls form section, and check the boxes for Live feed and Auto-number. This will allow users to see a live feed of the activity in the war room task table, and automatically generate the next war room task number for each new war room task.

Once you've checked the Auto-number checkbox, several new fields will show up. In the Prefix field, you might notice that WAR is populated there by default. This means that every war room task number will begin with WAR followed by 7 numbers. Since this is the same prefix we chose for our virtual war room records, let's choose something different. I went with WRT, but you could just as easily use four letters or even more.

Finally, replace the value from the User role field, with itil. This way, any itil user can access the war room tasks table. When you're finished, right-click the header, and click Save again. Congratulations, you've just created a table that extends the task table. This means that our new table will have fields like Active and Assigned to, as well as business logic, such as automatically deactivating after they've been closed.

Tasks are not meant to sit and be stagnant; they are meant to progress through a lifecycle. That lifecycle may include assignment, approval, and manual work; or it may be completely automated!

Workflows

Workflows in ServiceNow are flowchart-driven automation tools with a drag-and-drop interface. Workflows can be used to automate multi-step processes using various tools, including approvals, child-task generation, notifications, logical loops and scripting, if/then control flow, timers, and they can even wait for and react to user activity.

Versions of each workflow are stored in the Workflow Versions [wf_workflow_version] table. When a task matches the criteria set up for a workflow, that workflow will execute against that task, and perform activities on it. This relationship between one workflow version and one task, is called a Context. Contexts are stored in the Workflow Context [wf_context] table.

This setup is necessary because you might have workflow version 1 as the Published workflow version one day, and any tasks on that day will be executed with that workflow. However, if you make drastic changes to the workflow and re-publish it (thus creating a new version of the same workflow), you wouldn't want to start each existing task over from scratch; so the existing tasks would continue to execute with a given version of a workflow - whichever one was published when the task was created.

The graphical workflow editor (Workflow | Workflow Editor from the Application Navigator) gives you a visual representation of the contents and flow of a given workflow, in the form of a flowchart. Boxes in the workflow are referred to as (and correspond to) activities performed by the workflow. Lines drawn between the various activities correspond to the flow of the task, and are referred to as transitions:

When one activity in a workflow is completed, the transition executes the next workflow activity in the flowchart. In most cases, this transition is serialized or linear; from one activity to the next. Perhaps looping back, but always executing one activity at a time:

However, an activity can also have multiple lines drawn from a single exit condition, pointing to multiple activities. If this is the case, these activities will execute simultaneously:

In a situation like this, it's possible to save a workflow where one of these branches doesn't have an exit condition (a transition to another activity), but it isn't recommended. Instead, ServiceNow provides a Join activity, which you can use to merge the divergent paths back into a single transition-flow:

Not too dissimilar from the Join activity, Workflows in ServiceNow also have a Branch activity. However, using this activity is exactly the same as drawing multiple transition lines from a single exit condition on an activity!

As you may have noticed, each activity has a yellow exit condition at the bottom of the activity box. So far, the activities we've discussed have all had only one exit condition: Always. Clicking on the small square to the right of this exit condition, and dragging a line to another activity, allows us to create a transition from the first activity, to the next. However, some activities can have multiple exit conditions. The Join activity is one such example, as it has two exit conditions: Complete and Incomplete.

If you draw a transition from two or more activities into the Join activity, the Join activity will wait for all of the activities that transition into it, to complete before transitioning to the next activity. However, in some cases, an alternative execution path might terminate on some activity that never redirects back to the Join activity. If this happens, then the Join activity's Incomplete exit condition will be what fires; otherwise, the Complete exit condition will fire. Thus, it is a good idea to draw a transition from the Incomplete exit condition in a Join activity, whenever it's possible for a preceding activity to follow a transition path that doesn't necessarily lead back to that Join activity; otherwise, it's possible for your workflow to become stuck!

Important workflow activities

Now that we have a basic understanding of how workflows work, let's go over some of the commonly used workflow activities, how they're used, and what they're used for. We won't go over every possible workflow activity, but to give you a good sense of how things work with workflows, we'll go over all of the most popular and useful ones.

User and Group Approval

Approval - Group and Approval - User are both workflow activities that generate approval requests, but in different ways:

The Approval - User activity will create one or more approval requests for individual users. You can add both users and groups as approvers in this activity, but when adding a group, this activity will actually generate a separate approval request for each user in that group:

If you were to check the Advanced box, you could even use a script to generate additional users for approval, by setting a pre-defined variable (answer) to an array of Sys IDs corresponding to the list of users you'd like to request approval from (in addition to those specified in the Users and Groups fields.

In general, it's always best to either specify a group, or use a script to programmatically determine who the approvers should be, rather than hard-coding a list of users. Imagine if the user we've hard-coded as the approver for a certain type of request, leaves the company abruptly. Most companies have a development and approval cycle that takes days, if not weeks, to deploy a change to production, including workflow changes. However, certain things in ServiceNow are considered data, rather than configuration; data can generally be updated directly in production, whereas configuration (including workflows) generally cannot.

While workflows cannot usually be updated without a change request and approval, group membership and ownership can; so if we can use a script to grab the owner of a certain group, then all we have to do is make sure that if one person leaves the company, any groups that they manage have someone else put in the management field instead, so that approvals continue to function.

User approvals, like group approvals, also allow you to set the conditions under which the approval request is considered approved (or rejected). You can set it to Wait for: Anyone to approve, everyone to approve, the first response from any individual, of a condition based on a script. In a script, you could determine the total number of approvers, and then wait for more than 50% of them to approve or reject. Alternatively, you can set it so that if anyone rejects, then the entire approval request is rejected.

Finally, you can even set a Due date, so that users must reply within a specified duration.

The Approval - Group activity is highly similar to Approval - User, except that you can only specify groups (not individual users) to approve, and the Wait for conditions are more group-oriented: An approval from each group, an approval from any group, approval from everyone in all groups, and so on:

Approval Coordinator

The Approval Coordinator workflow activity is somewhat similar to a complex Boolean expression in programming, in that it allows you to generate an approval, the result of which is dependent upon the result of all of its child activities. Thus, you might have one Approval Coordinator activity that is fed by one Approval - Group activity, two Approval - User activities, and even a Manual Approval activity. You could then use the Approval Coordinator to make a determination as to the overall approval state of the record to which the workflow corresponds.

If

The If workflow activity does not so much perform an activity on its own, as it does control the flow of other activities in the workflow based on a condition.

A condition can be defined based on the condition builder (as seen above), or if we check the Advanced tick-box, we can write a script to determine if the If activity should return true or false. After clicking the Advanced tick-box, the Script field will be displayed. This field is auto-populated with a code-comment that provides a fairly detailed explanation as to how to use it:

Answer is a pre-defined variable in the context of this advanced condition script. This variable is a string, not a Boolean; it should be set to the string Yes or No.

After the script runs, whatever the answer variable is set to will determine whether the Yes or No exit conditions are activated:

You could use this script field, for example, to look up related or child records, and divert the workflow along another path depending on whether any related records were, for example, cancelled.

answer = 'no';
var gr = new GlideRecord('table_name');
gr.addQuery('state', '7');
gr.addQuery('parent', current.getValue('sys_id'));
gr.setLimit(1);
gr.query();
if (gr.hasNext()) {
   answer = 'yes';
}

Don't worry if the above code doesn't make much sense to you just yet, we're going to learn all about the GlideRecord class and the Glide API later in this book.

Switch

An If condition activity is perfect in the event that there are only two exit states: true and false, or yes and no. If you want your workflow to follow a separate path based on a particular field's value, such as the impact of a given ticket, you might find it more advantageous or convenient to use a Switch. A Switch pivots off a field's potential values, and works especially well with drop-down fields that have a fixed number of potential values:

While you can have each exit condition transition to a different activity, it's perfectly alright to have two or more Switch exit conditions transition to just one activity:

When the transitions (the lines between the activities) intersect, it can sometimes be difficult to see where each line ends up. To see the full path one line takes, just click to select and highlight it!

Wait for Condition

The Wait for Condition workflow activity allows you to specify either a simple condition (using the condition builder), or a script. Unlike a normal javascript function (but similar to many similar script fields in ServiceNow, the aim of this script is not to return anything, but to set a pre-defined variable (called answer) to either true or false. You can do just about anything you can do in any server-side script, but whatever that variable is set to after the script finishes running, will be the result:

One thing to keep in mind about the Wait for Condition workflow activity, is that it is only (re-)evaluated when the record that the workflow is associated with, is updated. Any update will trigger the re-evaluation of this condition, but updating another record will not. To help us understand this, let's imagine the following scenario:

Imagine that you've got a workflow associated to an Incident ticket, and that workflow runs a script which generates another outside record in a custom table that extends Task [task]. Next, the workflow transitions to the Wait for Condition activity. The Wait for Condition activity is configured to wait until that outside record is closed, which it determines via a script. However, the Incident workflow won't have any idea that you've updated the outside record once it is closed, so you'll need to give the incident a little nudge to get it to re-run the evaluation script.

One effective way of solving this problem, is to associate these two tasks together, and then use a business rule to update the parent record. For example, when generating the record in the custom task table, you can populate the Parent [parent] field with a reference to the record that the workflow is running on. You can then use a business rule on that custom table, that runs when it's closed, and updates the parent record by adding a work note. That will effectively nudge the record, and the workflow will re-evaluate the condition.

As with most records that have both a Condition builder field, and a Condition script field, those fields in the Wait for Condition activity must both evaluate to true, if used.

Create Task and Catalog Task

These two workflow activities are very similar; the primary difference being that the Catalog Task activity specifically creates a record in the Catalog Task [sc_task] table, whereas the Create Task activity can generate a record in any task-derived table.

One important thing to remember about the Create/Catalog Task activities, is that if the Wait for completion tick-box is checked, then the workflow will halt on that activity until the task is placed into a completed state:

If you want to get a pre-defined set of fields (fulfillment group, assigned to, short description, and so on.) and populate them, set the Task values from field to Fields. Setting the Task values from field to Values instead, allows you to set each field value as you prefer, more granularly. In either case, you can check the Advanced tick-box, and use the script field to set any field value on the generated task record. Since the script executes after the values are set from the static fields above it on the activity form, any values set via the script take priority:

Branch and Join

As we learned at the beginning of this section, the Branch workflow activity behaves exactly the same as if you were to draw multiple transition lines from a single exit condition, whereas the Join workflow activity allows you to merge multiple transitions into a single path, including the ability to wait for each input path to terminate or transition into the Join activity before moving forward.

Return value

Workflows, like functions, can call one another. It's possible to create re-usable workflows for commonly used processes, such as change approval, and then call them from the current workflow by simply locating one in the Workflows tab of the workflow editor, and dragging it into the main Workflow window:

In one of these workflows, you can use the Return value workflow activity to return a value back to the parent workflow, just as you might when using the return statement inside of a function in JavaScript. In the Workflow subflow activity on the parent workflow, the Map return value to field allows you to specify the variable name to use to store the returned value. You can access this variable from the scratchpad by using workflow.scratchpad.variableName:

Run Script

The Run Script workflow activity is fairly straightforward, in that it pretty much just provides you with a script input box. This script, like all workflow scripts, has access to the workflow scratchpad, runs server-side, and can reference the record that the workflow is running against using the current object.

Set Values

Much like the Run Script workflow activity, Set Values simply allows you to set one or more fields on the record against which the workflow is running, to specific values. This is often used to set the State field, modify the actual start/end dates, and so on:

Note that, as with most Set value fields, you can dot-walk in this workflow activity to set values on related records! For example, you could set the parent.state field, if the record your workflow is running against is expected to have a parent, and you'd like to change the parent record's state based on something happening in the workflow.

Workflow Stages

Workflow Stages can give users a general sense of the state and progress of a given ticket, in a visual and easy to understand way.

If you've been following along, you may have noticed that each activity we've looked at, has a Stage field on it. This allows you to specify what stage the workflow is at during this activity. For example, while waiting for a Fulfillment task to complete, you might set the Stage field to Fulfilment.

Which field on the table should be used to store the Stage value, can be specified in the workflow properties from the hamburger menu. Also in the hamburger menu, you can see and edit the workflow stages built into the workflow:

Demo

The simplest possible workflow in ServiceNow, is a straight line from Begin to End:

However, this workflow doesn't to very much for us. Instead, let's create a new Workflow for our virtual war rooms, to drive the generation of some war room tasks. To get started, open the Workflow Editor from Workflow | Workflow Editor in the Application Navigator.

The Workflow Editor should open in a new tab or window. When it does, click on the Plus icon at the top-right, under the Workflows tab, so we can create a new workflow for our Virtual War Room tickets:

On the New Workflow form, set the name to War Room, the Table to Virtual WarRoom [u_virtual_war_room], and fill out a description of your choice:

Leave the Conditions section blank, and click Submit. You'll be presented with the simplest possible workflow to start with, and it'll automatically be checked out by you. Workflows exists in the Workflow Versions [wf_workflow_version] table. When checked out, the Published [published] field in this table is set to false. The same is true for older versions of the workflow. Each time you check a workflow out and then check it back in (also known as publishing it), a new record in the Workflow Versions table is created:

If you publish a new version of the workflow while an existing published version exists, then the existing record has its Published field set to false, and the newly published record has its Published field set to true. Since we've only just created this workflow, there will only be one workflow version called War Room, and since we have not yet published it, the Published [published] field will be set to false:

In our imaginary company, Major Incidents are incidents with a high impact and priority. These incidents result in a Virtual War Room being created to validate the issue being raised, coordinate troubleshooting and resolution, and get the incident resolved as soon as possible. Once resolved, the major incident process will hand-off to the Problem Management process which, per ITIL methodologies, will be tasked with identifying a root cause for the major incident, and preventing future occurrences by creating new knowledge articles, performing a change request, or otherwise taking steps to prevent this major issue in the future.

Since we're building virtual war rooms to be a response to major incidents, let's make it so virtual war room tickets follow this process in our workflow:

1. A validation task is created first, in which the service desk agent must ensure that the incident is indeed a major incident, and was not miscategorized. The workflow stage will be Validation for this task.
2. After the validation task, a diagnostic war room task is created, and assigned to the Major Incident Response Team group, and the workflow stage is set to Diagnose.
3. You can create this group from the Groups [sys_user_group] table by just specifying the name and leaving all other fields blank.
4. Once the diagnostic task is completed, a Perform Fix task will be generated. During this task, the stage will be Fix. Once completed, the stage will be set to Complete before transitioning to the End activity.

In order for this process to work, we'll obviously need to create some task records. It's important to understand that tasks should never be created directly in the base Task [task] table; so let's create a new table, just like we did in a previous chapter. This new table will extend the Task [task] table, just like the Virtual War Room table does. Since we've done this once before, here are the bullet-points:

1. In the application navigator, navigate to System Definition | Tables, and click on the blue New button at the top-left.
2. On the New record form, enter War Room Task for the label, and press Tab. Once you've done that, the Name field should auto-populate.
3. In the Extends table field, enter Task, and select Task [task].
4. Leave Create module and Create mobile module checked. Set the Add module to menu option, to Virtual War Room.
5. Move to the Controls form tab/section. Check the Live feed checkbox and the Auto-number checkbox, then enter WRT.
6. Finally, right-click in the header and click Save.

Now that we have a table we can create War Room Tasks in, we can begin building our workflow. First, let's set up the stages for our workflow. Click on the hamburger menu at the top-left of the workflow editor, and click Edit Stages. Click New, and give the new stage a name of Validation, and a value of validation. Click Submit. Repeat this process to create Diagnose [diagnose], Fix [fix], and Complete [complete] stages.

Next, click on the Core tab on the right side of the Workflow Editor, and navigating to Tasks | Create Task. Make sure you don't have any other activity selected in the workflow, and double-click Create Task. In the corresponding form, set Name to Validation Task, and set the Stage field to Validation.

Next, under the Basics section, set the Task type to War Room Task [u_war_room_task], and make sure that the Wait for completion tick-box is checked.

Scroll down to the Populate task variables form section, and set the Task values from field to Values, and use the Set values section to set Short description to Validate Major Incident Priority and Impact:

Once that's all filled out, click Submit and a new workflow activity will be created at the top-left. Drag it into the middle of the workflow designer, then delete the transition line connecting Begin and End by clicking on it, and pressing the Delete button on your keyboard. Next, drag a line from the exit condition Always on the Begin activity, to the Create Task activity we just created:

To insert a new workflow activity in-between two others that are connected by a transition line, it is not necessary to delete and re-draw the transition. Instead, simply drag the new activity on top of the transition line so that it turns blue, and release!

Now repeat that process to create two more Create Task activities:

1. Name: Diagnose Task

1. Stage: Diagnose
2. Task type: War Room Task [u_war_room_task]
3. Wait for completion: true
4. Task values from: values
5. Set values: Short description - Diagnose the issue, and identify a possible solution

1. Name: Fix Task

1. • Stage: Fix
   • Task type: War Room Task [u_war_room_task]
   • Wait for completion: true
   • Task values from: values
   • Set values: Short description - Fix the issue to resolve the major incident.

If you have a workflow activity selected while creating a new workflow activity, the new one may appear inside the selected one, as part of it. To avoid this, make sure that no other activities are selected when creating a new workflow task.

Next, create one more activity by double-clicking Set Values under the Utilities folder in the Core tab on the right of the workflow editor. Set the Name field to Close War Room, the Stage field to Complete, and in the Values section, set State to Closed Complete. Remember that this State field is on the Virtual War Room against which the workflow is running, not on the war room task!

Finally, complete the transition lines so that the workflow progresses from one activity to the next, in the order we defined on the previous page. It should look something like shown in the following screenshot:

Now, simply publish your new workflow from the hamburger menu on the workflow editor, and you've got yourself a functioning workflow!

Approvals

To automate all business services would be the dream of nearly any IT director. With ServiceNow, an astonishing degree of automation is possible, but some things must still be left to human hands. One example of a primarily human-driven process, is approval. Sure, we can set up automated approvals for a number of different circumstances. For example, orders of new hardware with a cost under a certain amount, by a manager can all be auto-approved. However, if an individual contributor is submitting a change request to alter a firewall rule for example, that would likely need some review.

Approvals can be requested of individual users, or of entire groups. Approvals requested of individual users, are stored within the Approvals [sysapproval_approver] table, whereas group approvals are stored in the Group Approvals [sysapproval_group] table. Approvals can be generated via approval engines, or workflows; the more common of the two being workflows. We went over these approval options in some detail in the Workflows section of this chapter.

Assignment

Probably the most common means of moving a task forward, is assignment. Assigning a task is the way to designate a user or group or users, as those responsible for the fulfillment of a given task.

The base task table (and therefore, all tables which extend it) contain two assignment fields: Assigned to [assigned_to], and Assignment Group [assignment_group]. If you've enabled visual task boards, then you'll also have the Additional assignee list [additional_assignee_list] field.

Assignment drives a lot of default notifications, such as alerting the assignee when work notes are added by another service desk agent, or when the customer leaves comments. It's usually a very important part of the task-handling process.

Creating Task fields

One thing that's important to understand about Tasks in ServiceNow, is that all task records (whether they're changes, problems, incidents, requests, request items, catalog tasks, or tasks in any other table that extends the base system task table) are technically all stored in a single database table. Although in ServiceNow, you see them as separate tables, that isn't actually the case. This is due to the flattening of the task table.

Each task-extending table has a field called Task type [sys_class_name], which defines what type of task it is (problem, change, incident, etc.). ServiceNow groups records with the same Task type, and treats them as though they're all in separate tables, but in the physical database on ServiceNow's servers, they're technically all in one big table.

This fact has far-reaching impacts on the way that the task table should be handled, some less obvious than others. For example, say you want to create a new field on the Incident form: Assigned developer [u_assigned_developer]. It's absolutely fine to put this field on the Incident table, and the Dictionary [sys_dictionary] will keep track of things for you; things such as where this field actually resides within the task table structure. However, what if you want to add the Assigned developer field to the Change table too, in case you have a change that requires a development effort? And while you're at it, perhaps you'd like to add it to the Problem and Requested Item tables. Well, in that case, it may make more sense to add the field to the base task table. This way, you don't need to have multiple copies of what is essentially the exact same field in the same database table (even though you wouldn't see it as being in the same table, since ServiceNow displays each task-extending table as a separate one!)

Here are some things to consider when it comes to the task table:

• Try not to create new fields from the Form Designer. Instead, navigate to the Table Dictionary record for the table you'd like to create a field on, and create it from the related list of fields. This is because creating fields in the form designer often creates them on the base task table when you don't intend to, and doesn't give you much control over the name, type, default value, and so on.
• Think very carefully before creating new fields on either the base task table, or any table that extends it. Think both about whether that field is necessary (could an existing, possibly unused field work?) and if so, about where it should be created (on the base table, or the extended table?).
• When creating a new table where work might be done or tracked, carefully consider extending the task table. If you need features like workflow, an activity log and work notes, or assignment, you might be better off creating a table that extends task, rather than standing on its own.
• Be extremely judicious about modifying the base task table. Any time you can avoid it, it's almost always best to create a Dictionary Override on the extended table, rather than modifying an existing base task table field.

Please Bookmark and helpful if you find any help from it.

Regards,

Ganesh

[Prasant Kumar 1]

Helpful

[Claudio Cruz1]

Awesome!

[Claudio Cruz1]

What book is this??

[Gaurav Shirsat]

This is very Informative Article. Excellent

[sai prasad1]

how to create incident task for a incident, 

for example: In incident form , there is  checkbox . Whenever it is checked I want to create a incident task .

[sai prasad1]

How to do this in workflow editor

[Unzur]

Its Very Helpful

[Sai 7]

Hi @Ganesh Pardhe

 Thanks for the information you have provided, Can you  give any  10 real-time scenarios for workflows? This will help me to get more knowledge on this topic. 

Thanks in advance.

[rafaelmolin]

What is the difference between Workflow Editor and Flow Editor?