7

Designing Effective Processes at Scale

One of the most powerful capabilities of the ServiceNow platform is its ability to help an organization structure, standardize, and automate its processes. In this chapter, we provide an overview of the platform’s automation capabilities and share some considerations around how to leverage them in a scalable and maintainable manner.

This chapter is divided into two major sections:

• An overview of ServiceNow’s process automation capabilities and archetypes
• Designing process automation using platform building blocks and data

By the end of the chapter, you will be well equipped to spot opportunities where ServiceNow can be used to deliver organizational value and understand what you can do to estimate the complexity of the effort. You will also become familiar with the building blocks with which you can create the value-enabling process automation at your organization.

ServiceNow’s process automation capabilities and archetypes

ServiceNow’s process automation capabilities are underpinned by five major elements – integration APIs, service portal and digital forms, data-driven workflows, tasking and automated actions, and foundational shared data across the platform.

These elements work together to provide automation across processes. The typical flow follows this pattern:

1. A customer who wishes to engage in a particular process looks for that process’s form in the Employee Service Center. An example would be Obtain a new laptop or Offboard an employee.
2. The customer is presented with a digital form and/or a checklist that they must fill out to start this process. This form may include error checking or logic that validates whether the customer is eligible to engage in the process and whether other options are available to them.
3. After the customer submits the form, the workflow engine uses the information provided by the customer via the digital form and underlying foundational data to create the appropriate tasks to be sent to fulfillers and/or performs automated actions to complete the process. During this time, fulfillers or customers may also be prompted to provide additional information, either through a task or through an email/chat.
4. The entire lifecycle of the process is tracked by the system, so the customer and agents have visibility of where the process is:

Figure 7.1 – A typical process automation design pattern on ServiceNow

Another common pattern of process automation for the ServiceNow platform involves an automated event or action captured by integrations that trigger the workflow engine to generate tasks or perform additional automation steps in response. This archetype is typical in event management use cases, such as when a monitoring solution detects an anomaly or actionable event and sends that information to the platform via integration. Once received, the platform can process the event, evaluate rules against the event, and then create manual tasks or take additional automated actions to resolve the event.

Figure 7.2 – The event management automation pattern in ServiceNow

The ServiceNow platform provides a number of different technical components to help you automate these two archetypical process automation patterns. Each technical component deals with one or more steps of the archetypical process automation flow. When designing process automation on the platform an important design choice is what technical components are the most fit-for-purpose to fulfill the requirements. Let’s have a look now at the various technical components available to you and which part of the process automation pattern they service.

Technical components of the platform that deal with event intake or user input

For both the process automation patterns we have outlined previously, there’s a triggering event or action, either from a user or a system. ServiceNow has a variety of ways of capturing these triggering actions. Let’s look at the major ones.

The Service Portal and the Service Catalog are two major technical components that can be used to capture user input as triggering actions. The Service Portal is a customer-facing web portal that serves as a single stop or hub for a customer to be able to find the digital forms they need to trigger a particular process. The Service Catalog is where all digital forms are located and categorized in the catalog for easy searchability. The portal and the catalog work together as end users visit the portal, which contains the Service Catalog. The portal also provides search functionality to enable users to find catalog items easily without having to browse the individual catalog categories. The Service Catalog is a listing of digital forms, and ServiceNow has more than one technical component that provides these digital forms.

Record producers, order guides, service requests, and HR service are all technical components of the platform that enable the creation of digital forms. Record producers are the least specialized technical capability on the platform to produce digital forms. They allow for the creation of forms that can be presented to the end user and processed in whatever way the developer wishes, prior to the triggering of workflows. The record producer logic can even execute scripted code without the need for any workflows. The other technical components listed are more specialized features, intended to simplify or provide additional functionality for a specific domain or problem. In many cases, they are built on top of and take advantage of the record producer and order guide capabilities, adding additional functionality specific to its domain.

Service requests are built to provide a consumer shopping website experience. Service request forms are built within a framework that provides shopping carts, adjustable quantities, and pricing and price calculations. Service requests are at their best when used for the creation of digital forms that represent the ordering of physical goods, providing an online shopping experience out of the box.

The order guide may be used to create a wizard-like experience for the request process. An order guide is simply a digital form that can then trigger the addition of other digital forms as part of an order. For example, an order guide form for an employee to request a laptop may ask the employee in a single form about their peripheral requirements (for example, do you need a mouse, trackball, or a stylus?) and automatically generate a separate request for the peripherals instead of having the end user fill in each as a separate form.

The HR Service module is specific to the HR Service Management (HRSM) capability of the platform and augments the capability of record producers for HR-specific scenarios. The most important thing to keep in mind when considering the HR Service module in your design is that the digital form component of the module is simply a record producer. The HR Service module adds additional HR and HR-portal-specific configuration around a particular record producer identified as part of the HR service request to provide additional platform capabilities (such as lifecycle events).

You may also have the Customer Service Management (CSM) module, in which case there is also case management which are records designed specifically to capture various case types from external customers. Record producers are used as the forms to capture customer information to populate cases.

The information provided might feel overwhelming. Why does the platform have so many different ways of doing similar things? Some of it comes down to history and backward compatibility, but in other cases (such as the HR Service), it comes down to specialization of functionality. To simplify your choices, first identify broadly whether the process you wish to automate is an HR-specific process, a customer service process, or an IT process for employees, then pick the appropriate technical component (HR Service, case management and record producers, or service requests, respectively). Taking this approach, you will rarely make the wrong choice.

Web services are a platform capability that allows ServiceNow to provide REST or SOAP API endpoints that can be accessed by other systems. ServiceNow offers multiple ways to receive API calls, including the Table APIs, which enable other systems to perform CRUD operations on ServiceNow tables and scripted APIs that allow you to script complex behaviors upon receiving the inbound API calls. The ImportSet Table APIs allow web services to populate an import set table, which then runs corresponding transform maps to write the incoming data to a target table after undergoing a transformation process. Regardless of which web service options you choose, inbound API calls are the foundational platform capability that enables the triggering of workflows and actions from external systems and other platform capabilities. For example, Event Management, the ServiceNow module that is specialized in ingesting events from external monitoring tools and then triggering the creation of tasks via workflows or event rules, leverages web services for any push-based events coming from external systems.

The Management, Instrumentation, and Discovery (MID) Server is a Java application that runs in either a Windows or Unix environment on your local network. The MID Server enables ServiceNow to communicate with and execute commands and actions within your network environment. This platform capability can be used as a triggering action for various process scenarios, the most obvious out-of-the-box triggering actions being those provided by Service Mapping and Discovery. These capabilities utilize the MID Server to detect your infrastructure and services and monitor them for changes. A change in the environment detected by Service Mapping can then act as a trigger point for certain processes to engage, such as the creation of unauthorized change tickets.

Business rules and scheduled jobs can be used to trigger workflows based on changes or events occurring within ServiceNow. For example, a workflow may be triggered when an asset record’s state is manually changed to To Be Retired. Business rules can detect data changes as they occur, while scheduled jobs may be used to scan the system periodically and then trigger actions appropriately.

Any of the preceding platform capabilities can be used to facilitate the capture of a triggering action or event, either from a user or system. As part of that capture, information may be collected; for example, a record producer or service request form may ask the user to provide information, such as what model laptop they want or whether they will be working outside of the office. The additional information collected, along with the triggering action, can then be used for the next step of the process automation pattern – workflows.

Technical components of the platform that manage workflows

Workflows are a series of pre-configured steps that execute automated actions in sequential (and occasionally parallel) order based on programmed rules. For example, a workflow may take a service portal form for a new laptop submitted by an employee, use the form submitted to determine where the closest stockroom to the employee is, and create a task and assign it to the IT service desk team at that stockroom to prepare the laptop for pickup by the employee.

ServiceNow has multiple technical components that provide workflow automation capabilities, the most obvious (but also deprecated) capability is the one aptly named Workflow. This was the primary platform capability to enable process automation until the New York release of ServiceNow, at which point it was superseded by a new framework for designing process automation called Flow Designer. As a platform designer in the Tokyo release or later, you should be aware of the existence of Workflows, but your designs should never specifically attempt to leverage its capabilities except in very specific scenarios. As of the Tokyo release of ServiceNow, there are still some areas of the platform that utilize Workflow instead of Flow Designer; one such area is defining a CI remediation as part of the CMDB Health platform capability.

Figure 7.3 – The legacy Workflow capability of ServiceNow is still used in various areas of the platform

Flow Designer enables much of the same functional capability as Workflow but with a different interface, greater ability to debug and manage flows, and a modular design philosophy that encourages the reuse and composition of simpler components to create complex behaviors. The interface of Flow Designer, as seen in the next screenshot, is substantially different from the Workflow designer and follows a slightly different design philosophy. Still, its ability to launch a sequence of automated actions in response to a triggering event is comparable to workflows.

Figure 7.4 – Flow Designer is the new platform capability for any process automation scenarios

The lifecycle events capability in the HR Service Delivery application can be treated as a separate technical component built specifically for HR scenarios where a particular HR lifecycle event (for example, an employee is hired or transferred, or when health benefit renewals are imminent) may require a series of actions to be performed by employees and service fulfillers as part of the event. Lifecycle events are a powerful way to composite a variety of actions, forms, and steps together but were built specifically for HR use cases and therefore, limits their use except in that specific scenario.

Beyond these capabilities, ServiceNow offers the ability to use Script Includes to generate tasks and perform any action you desire, which can work as a bespoke workflow system, but as it is not purpose-built for this, we would not consider it a workflow capability comparable to the previously mentioned components.

From this point in the chapter, we will use workflow to refer to any of the aforementioned technical components. Workflows enable platform teams to manage and configure process automation in a structured way. They sequence one or more sets of actions performed by the platform in response to the triggering event and can pause before executing the next action in the sequence in response as it waits for user input or for additional triggering events to occur. Workflows provide the logic for when and what actions should be executed. The platform’s task management and automation capabilities allow it to perform those tasks as orchestrated by the workflow components.

Technical components of the platform that deal with tasking and the execution of automated actions

ServiceNow completes the process automation loop by providing a tasking, assignment, and script execution engine that allows workflows to create and assign tasks to the appropriate individuals and allows scripts to trigger automated actions to occur.

Tasks underpin many capabilities in the platform where a manually actionable activity is assigned to a human being; this includes customer service cases, IT service requests, and HR service requests. Tasks have multiple things in common with one another, some of the most important ones from a process execution standpoint being the following:

• Tasks are assigned to individuals or groups, who can then work on the task according to their priorities.
• Tasks can contain descriptions that may include both generic instructions to agents regarding how to complete the task as well as information collected from the users/automated event trigger. For example, a task created because a monitoring system detected a server that does not yet have the latest security patch might contain details on the server that was detected and the results of the scan that was performed.
• Tasks track their state, which can be changed via automation (for example, in reaction to some action taken by an agent or user against the task) or manually (for example, an agent indicating that they have completed the instructions provided to them by a particular task). The change of state in a task can then be used to coordinate follow-on activities by the workflow. For example, a workflow responsible for an employee’s onboarding may wait for a security compliance officer to mark a task in delivering workplace security policy training as complete before instructing the IT team to deliver laptops and access credentials to a newly hired employee.

ServiceNow also offers a specialized Approvals capability that, like tasks, is assigned to individuals or groups and has state. Like tasks, approvals can be used to coordinate process steps that are being automated by a workflow, such as when a workflow to send a purchase order to an IT hardware vendor waits for the approval of the finance team before proceeding.

Approvals differ from tasks in that they offer only a limited and specific set of actions against them – approve and reject. Approvals enable the capture of an approval or rejection reason from the approver when the action is taken and may be performed via the mobile application, email, or directly on the platform on a computer.

Tasks and approvals are ways for workflows to instruct humans to provide input to continue the execution of a process and scripts are a way for ServiceNow to trigger automatic actions as the process proceeds. Scripts can do anything on the platform – they can send an API call to an external system; update, create, and delete records; and even create tasks and approvals. Scripts in ServiceNow are packaged into different types of records, and the type of record determines when a script is executed and what information the script has available to it at the time of execution.

Script Includes are the most fundamental records for a script on the platform. A script included in a Script Include record is accessible by any other script in any other record in the system, and can be used to store re-usable code. For the purposes of process automation, one important record that may include scripts is Flows, including Subflows and Actions. These are Flow Designer components that can then be connected to support various process automation scenarios. Scripts inside Actions, Flows, and Subflows can perform automated actions in response to certain triggering events.

Workflows help determine the right actions to be performed at the right time, and tasks and actions enable those actions to be performed. The last step tying all the pieces together is foundational data, which helps workflows to execute at the right times for the right individuals, and tasks to be assigned to the right groups and provide the right contextual information to enable their completion.

Technical components of the platform that deal with shared and foundational data

Foundational data is the oil that lubricates the machinery of process automation. Many process automation scenarios of value require some type of foundational data to be on the platform, and in the best-case scenarios, great foundational data can improve reuse and reduce the need to build everything net-new in the face of new challenges and environments.

When we refer to foundational data, we specifically mean data that has the following attributes:

• It has a universally understood definition within the business
• The change (creation, update, deletion), storage (sources of truth), and usage of it is governed
• It is shared data that is the same data used by multiple business processes and means the same thing to each

From a ServiceNow standpoint, foundational data types are defined within the Common Service Data Model (CSDM). These include Location, User, Company, Contract, Product Model, and others. It is important to understand that the CSDM and the foundational data types that ServiceNow can accommodate out of the box do not satisfy the aforementioned criteria for foundational data. For example, the CSDM clearly indicates that Location is a foundational data type and defines a default set of fields that can be stored within that record, but it does not provide guidance on whether locations should include the organization’s buildings, rooms, desks, or parking lots. It is up to organizational and platform governance to establish the right framework for Location foundational data to be stored and used on the platform.

From a design standpoint, the important aspect to understand about foundational data is that ServiceNow is prescriptive about exactly what types of foundational data it formally supports through the CSDM. Any process automation design requiring data matching of those foundational data types should make sure that the data type is under governance, and if so, consume the foundational data in the appropriate way as prescribed by governance. Should the data required not be under governance (for example, your service request requires the location data of storage closets that are not currently stored in the Locations table on the platform), the designer should engage platform governance to introduce the data as foundational data on the platform. This process may be time-consuming but is necessary to avoid redundant or poorly maintained data on the platform and to encourage long-term platform health.

With well-managed foundational data within the system, many process automation use cases may begin leveraging this data to more efficiently enable capabilities that would never have been possible if data requirements were designed on a requirement-by-requirement basis. Imagine, for example, that foundational room location data for heavily utilized office spaces of an organization is managed on the ServiceNow platform. A service request that manages the booking of rooms could use the foundational room data to enable employees to pick the available rooms they want to book, while a smart office monitoring system could monitor AV equipment in rooms and dispatch IT to conduct repairs on equipment, reporting errors by providing the room information. More powerfully, because the room data is foundational data, repairs in progress could then be reflected in the room booking service request to prevent employees from booking rooms that have faulty AV equipment. This is only possible because the room foundational data is used in both processes and therefore enables each process to be aware of the other through that shared data structure.

Now our review of the platform’s core capabilities to enable process automation is complete, it is time for us to put these capabilities into use, just as we did with foundational data, to create highly effective and reusable configurations.

Designing process automation by utilizing platform building blocks and data

With all the technical capabilities of the platform and an understanding of how process automation is composed using the major archetypical steps – trigger events based on user or system input, sequence actions and tasks via workflow, and complete tasks and continue workflow, you can now design process automation through these blocks.

The first step to designing process automation that works at scale is to know whether something is a good automation candidate. Thankfully, you should be able to use the archetypical steps outlined earlier in this chapter to identify them – those that follow the well-defined archetypical patterns are likely great candidates for automation via the platform, while those that don’t may still be candidates but with a greater level of configuration complexity.

Let’s look at an example. At a major international bank, a common and labor-intensive manual process involves the capture of emails from business banking customers requiring specialized services. Currently, customers submit their requests for over a dozen distinct service types via an online form that generates an email to a shared business banking service inbox. Once the email has been received, agents peruse the email to determine whether the customer is looking for one of the dozen services (for example, open a new account, obtain the last three years’ transaction history, apply for a business banking credit card) that they are able to support. If the email is for a supported request, the agents will verify via a document stored on SharePoint what information to collect from the customer and which specialized support team’s inbox the email should be forwarded to after all the information has been collected to fulfill the request.

Is the preceding example a good candidate for automation using the platform? We will use our archetypical steps to see whether it fits the pattern, by asking the following:

• Is there a clear triggering condition the platform can use to initiate the process automation? The answer to this is yes, as all the processes that can be engaged by the customer in this scenario start with the customer making the request themselves manually. This means that if we do use the platform to automate the request, we will likely leverage the service portal and a record producer or service request form to capture the customer request, or we might leverage the existing form the customer is using and send the information collected via integration to the platform. Either way, the trigger point is the customer clicking the Submit button on the form.
• Are there clear input data requirements that the workflow must consume to start sequencing actions and assigning tasks? In this case, the answer is again yes, as the agents currently have an existing list of specific requests that can be supported, as well as a list of specific questions to ask of the customer per request type. This data can therefore be structured in a digital form and captured up front prior to customer submission to save a valuable manual agent type and enable faster fulfillment of the request.
• Are there clear rules and logic defined in the process for the workflow to sequence actions and assign tasks based on the inputs? The answer is, of course, yes, as the agents have a well-defined way of determining which support team to ultimately send a request to based on rules captured in the SharePoint document. As long as the rules documented are deterministic (that is, the same inputs always result in the same behavior), they can be digitized and automated by the workflow so that humans no longer need to interpret and decide which team should be sent the fulfillment tasks.
• Are there requirements for foundational data, and is the required foundational data available? This is a tougher question to answer with the information available. If you are doing this design in the real world, you should immediately consider the foundational data elements that are likely involved in this scenario – customer information (account and contact) and organizational group information (assignment group) come directly to mind. There are also foundational data elements that may need to be established that are not yet available; for example, as you digitize each possible request for a service with its own intake form, you may find that some of the information you need to collect from the customer is better served when managed as foundational data. Some examples of this are branch information (location) and the customer’s preferred contact information, pass-phrase, or other data that can help you authenticate the customer during support calls. As part of your design, you should try to produce a list of the data requirements and engage the platform architect to determine whether these requirements can be met using existing foundational data and what to do if some data requirements do not currently exist on the platform.

A final aspect of determining whether a process should be automated at all has nothing to do with the platform’s capabilities; it’s simply whether automating the process can generate value for the organization. As covered heavily in earlier chapters of this book, any configuration of the platform should be considered in terms of the value provided. In the preceding scenario, reducing the need for agents to manually route and obtain customer information may save agents one minute per request. This might not be worth it if the request volumes are small but may provide enormous value if the request volumes are very high. As an aside, product owners should also consider the value of increased service quality as opposed to just cost-cutting. A one-minute saving per request may mean greater service throughput overall and, therefore, greatly reduce service fulfillment times for each customer, resulting in value through better customer satisfaction.

Now, suppose we bumped into a potential process automation candidate that, in the end, failed to pass the preceding checklist. What might that look like, and how might we change the current state in such a way that we have better automation opportunities? The common failure scenarios for each of the preceding checklist items are listed as follows:

• Processes might fail the clear trigger condition check if the process itself is comprised of many subprocesses, some of which may be ill-defined. In such a situation, an immediate clear trigger condition may not be capturable because there are hundreds or even thousands of ways a process may be engaged. When you encounter such a situation, platform or process owners looking to automate should work with the process fulfillment teams to remove the ambiguity and/or to differentiate the various distinct processes to simplify the design of capturing the triggering event.
• When organizations have yet to mature their services to an extent where they are automatable, you are almost guaranteed to encounter at least one process where the required information to be collected from the service requestor is ill-defined. Sometimes this ambiguity has a compelling cause; for example, a service request to perform an engineering assessment on a building under construction may be complex enough that some back-and-forth data collection and understanding is required even if the obviously required data points are well-known. ServiceNow can support such complex scenarios where a case or request is comprised of a series of interactions and transactions, but it is certainly not specifically designed for such use cases.
• In the case of workflows and assignments, automation value may be lost or limited if the organization struggles to understand its own task flows. This can occur when a task assignment is heavily augmented by the agent’s understanding of underlying team dynamics (for example, Tim has experience handling database issues while Stacy is a whiz at troubleshooting deployment scripts. Both work on the network team, but tickets from experienced service desk agents always find them and are resolved quickly, to the delight of customers). While this type of knowledge is not bad in and of itself, over-reliance on it to deliver great service can seriously impact the scalability of the organization. As teams become larger, training, separation, and specialization of capabilities and accountabilities become increasingly important to enable the team to scale efficiently. Additionally, these qualities also happen to benefit automation, as it enables patterns to be created (or inferred), which places the right cries for requests with the fulfillers and fulfillment teams with the right skills at the right time.
• Foundational data issues may prevent both the rapid scaling of automation technologies and the ability of automation technologies to deliver a positive return on investment in the first place. There are two common foundational data gaps for any large organization. In the first pattern, the foundational data of the kind needed to automate a specific process is available, but the data is of poor quality or difficult to access due to security or organizational restrictions or limitations. In this case, the focus should be on maturing the governance processes and investment around that data so it can be elevated to the level of quality to support the use case. In the second pattern, the data required may not be available at all. This may mean the data itself is entirely non-existent or that the data lacks the detail or specific information to enable the use case. Resolving the second scenario may be complicated by the reality that foundational data may be costly to maintain and that a single use case may not justify the introduction of a new foundational data type to be maintained by the organization. In such scenarios, platform and organizational governance must be engaged to establish the appropriate business case and design for the new foundational data. It may help to gather multiple use cases that could take advantage of the foundational data to form a stronger business case. The bottom line is that it will typically take collaboration, coordination, and funding across multiple business stakeholder groups to create the new foundational data and that the introduction of new foundational data to the organization is typically only tenable when multiple use cases can be identified and achieved together or as part of a roadmap to justify the overall investment.

Understanding the preceding failure scenarios should enable you to avoid implementation pitfalls ahead of any substantial commitment of resources. Treat the failure conditions as a set of risks for the project to be validated and mitigated up front to improve your chances of implementation success and of providing actual value in the attempt to automate your business process.

Now that we have the tools and checks to identify good automation candidates, let us discuss the considerations that can make the configuration performed by your platform team more maintainable and manageable, beginning first with the idea of creating common patterns.

Creating repeatable and reusable patterns to ease implementation complexity

The reuse of configuration is a tried-and-true technique to reduce the overall complexity and cost of existing code maintenance and new code builds. With code, the use of methods, functions, and objects enables multiple use cases to be achieved by reusing these components. Similarly, with workflows and forms, ServiceNow provides the capability for reusable components to be created, which can then be used in multiple scenarios. There are multiple advantages to this approach. First, smaller building blocks are easier to test. For example, it may be very complicated to test a ticket booking application end to end where a user submits a form, the form is sent to an agent to be validated, and then an API call is made to a vendor system to pay and then eventually receive a ticket number and unique digital ticket. The build and testing of this application would be vastly simplified if it were divided into a series of independent configuration components. One component may be a form that collects user data, one component deals with the validation of the form information and routing the form to the appropriate agent, another component manages the collection of payment information and the sending of payment information to the vendor system, and finally, a component processes the vendor system response and reacts appropriately.

ServiceNow not only enables this separation of configuration into multiple parts via individual scripts and functions, but it also enables this composition pattern in its workflow designer. The most important platform capability to know in the case of creating repeatable workflows is Flow Designer. Flow Designer offers Subflows and Actions, both of which are meant to enable platform developers to create repeatable components that can then be leveraged by multiple flows, achieving an ideal build and test once, reuse many times situation. The biggest difference between a Subflow and a Flow is the lack of a trigger condition. Subflows are triggered by Flows (or other Subflows) instead of being triggered due to a change to a record. Once a Subflow or Action has been created, new Flows can leverage these components, pass data into the Subflow or Action, and then collect the outputs of that Subflow or Action once they are complete.

For digital forms, ServiceNow’s Service Request capability has two major components that can help with reuse. First, variable sets can be created, which package up a number of elements that can appear on a form and enable the behavior to be defined once and then reused on multiple forms. The most common example is a variable set created for any physical goods-based orders, which asks a user to input their preferred pickup location and preferred pickup time. The preferred location and preferred pickup time fields, along with help text and any form behavior, may be grouped into a variable set, which can then be added to any new form that involves the order and delivery of a physical product to save development time.

Order guides in ServiceNow provide a different way of reusing configuration: they provide a form that collects user input and then helps select and automatically fill in other forms, such as service requests.

Leveraging these capabilities, designers can identify appropriate functional components that can then be made reusable. Luckily, there are many such patterns that are universal across organizations and processes:

• Approvals: These are commonly repeated workflow patterns that can be made into a Subflow and then reused across multiple processes. Many processes, from ordering laptops to requesting a corporate credit card, may require approvals from a manager or senior executive before they can be fulfilled. The act of sending approvals to the right individuals and pausing the workflow until the approval has been granted is a common Subflow pattern that can be used across multiple processes.
• Repeatable service request form elements: As mentioned earlier, these are always great candidates for the use of variable sets. It is best to group these elements into variable sets when there is a clearly repeatable functional purpose, such as to prompt users for their preferred pickup location and time, to prompt the user on whether the request is being made on behalf of someone, and if so, to ask for information related to the intended recipient of the request. It is usually not recommended to group form fields that are unrelated to each other but commonly appear on the same form together. For example, even if the preferred first name, last name, and short description of the request frequently appear together, they may not be the best fields to be included in a single variable set, as the functional purpose of collecting first name and last name is different from the functional purpose of collecting a short description of the service requested. In such a case, a variable set can be made to collect the user’s preferred name information with the preferred first and last name fields, while a short description can be kept in a separate variable set.
• Repeatable sets of tasks: These can commonly be created as Subflows. Many organizational processes may involve repeatedly performing the same series of activities. An example may be the shipping of a physical device to a particular office location. Regardless of the physical goods shipped, the mailroom needs to request and print a new shipping label, package the physical goods that are to be delivered, affix the shipping label to the package, and then bring the goods to be shipped to the shipping dock area of the mailroom. This series of actions may be created as a Subflow agnostic of the type of goods that needs to be shipped. Specific workflows for the shipping of goods can then reuse this Subflow and only provide additional differentiated steps for the preparation of the physical goods.

While repeatable components are a good start for scalable and maintainable design, there is a limitation – some repeatable components may differ in small ways that prevent repeatability. For example, while many processes may require a two-level approval, the individual who must do the approving is not the same for every request of the same type. An extreme example of not using data to drive this workflow would be to create a workflow for every unique approver. To avoid this issue, an additional design element must be leveraged for true reusability: that of data-driven components.

The concept behind data-driven repeatable components is to create repeatable patterns that act on specific input data. In the case of approvals, for example, instead of creating an approval Subflow for every person who may be able to approve a task, create an approval flow that sends the approval to a user or group that is designated as the approver or approval group for the user making the request. In this way, the variable input data of the user’s approval group is provided separately from the repeatable behavior, enabling the creation of a repeatable approval Subflow that can send approvals to any user if the required approval data is provided as the Subflow input.

When creating your Flows, Subflows, scripts, or other components, consider what data elements being used in the design can be decoupled from the behavioral configuration and passed in after the fact to maximize the decoupling of your behavioral components from the underlying data sources.

Now that we have looked over some of the fundamental design principles of creating scalable and reusable designs let us summarize with a checklist of good software design principles that can be used to assess any design for its reusability and scalability:

• Reusable components should be decoupled from concrete data sources: If a Flow, Script, or piece of code requires specific data to function, the data should be passed to it as an argument or triggering object. This provides easy reusability when the data source changes, easier automated testing (through mock input data or mock data sources), and configuration understandability (by enabling developers to immediately see all the data needed by the component to function).
• Reusable components should follow the single-responsibility principle (SRP): This is a computer programming principle coined by Robert C. Martin in the article The Principles of OOD, which states that “A class should have only one reason to change.” The concept behind this statement is more easily illustrated by an example. Suppose there was a Flow responsible for triggering the ordering of computer hardware (laptops and desktops) when new employees are hired. Such a Flow may be triggered by the hiring of an employee and may determine what hardware needs to be ordered by the employee’s level and role. If built as a single Flow with no sub-components, then the Flow might need to be changed either because the event triggered by the hiring of an employee changes or because the rules for what hardware needs to be ordered for employee levels and roles change. In such a scenario, it is better to split the Flow into sub-components, one responsible for triggering the appropriate order process, and another that determines what hardware must be ordered according to the hired employee’s role and level.
• Reusable components should avoid being stateful: Stateful means that a particular Flow, Script, or other component relies on knowing the state of a system to effectively do its job. Another way to think about stateful configuration is that the component displays different behavior based on what occurred before the component was engaged. In contrast, a stateless technical component does not care about or need any information beyond what is provided to it as its input to perform its function. Stateless components are a lot easier to test, as any data points needed by the component can easily be provided to it through mock test data, which also means that it is easy to automate the testing of different branches of logic by varying the test data as needed. In contrast, stateful components can be difficult to test as not only must input information be provided, but other dependent state information may also need to be set up prior to running the test scenario. Stateful components are also much harder to debug and for team members unfamiliar with the configuration to understand as they contain dependencies on many hidden variables that may not be obvious through casual inspection, therefore, impacting the scalability of the team.

Armed with the preceding principles, your team will be on its way to creating more reusable and scalable process components that can enable more rapid automation over time. Never forget that automation and creating better building blocks to enable faster automation is a continuous improvement process – regular code reviews, cleanup and refactoring of cold designs, and targeted re-engineering are needed over time as the team draws from previously learned lessons and as the patterns of business requirements and needs shift with the times.

Reusability, testability, and scalability are major software engineering disciplines about which thousands of books and articles have been created and written, most of them applicable to more than just ServiceNow. We strongly encourage your team to dive further into the topic as your capabilities mature and as you move to increasingly higher levels of automation.

Summary

In this chapter, we discussed how ServiceNow provides process automation capabilities to the organization through multiple technical platform components. These components are either specialized for specific purposes, such as HR Service Delivery, or are generalized and used as building blocks for process automation across use cases, such as Flow Designer.

Not all processes are great candidates for automation immediately, and before a team begins the process of automating a process using the platform, they should do preparatory work to identify and prepare foundational data and remove ambiguity in decision-making in the existing process so that it can be easily automated.

Finally, we discussed how thoughtful design and the use of technical platform components can improve reusability, allowing teams to quickly deliver new automation, leveraging existing pre-configured capability. The creation of reusable components decreases the risk and complexity of new configurations by reducing the number of tests required and by improving the ability of the team to test, which is critical to scaling up the automation capabilities of the organization.

The ability of your platform team to automate processes is only one of several crucial factors in achieving value from the platform. In the next chapter, we will look at how the governing and guiding processes of your organization can have a significant impact on value realization, and how to structure them for the best results.