1.1 What is the Performance Review Application?

The Performance Review application is a Scoped Application created by your company to collect and store performance reviews of employees and their managers. The application scope stores data in a single table, Performance Review (x_1310421_ccl127_0_performance_review), where all the magic happens. Records from this table store the individual review period (schedule) of the Performance Review, the Employee's self-review fields, and the Manager's performance review fields.

1.2 Why are we here?

The Performance Review record has numerous views indicating multiple attempts to keep this information clean and easy to follow. Numerous attempts have been made to keep these cumbersome forms as user-friendly as possible. Now, it's time to take advantage of Playbooks to bring these forms up to snuff.

1.3 Review the Record

• Navigate to: "CCL1270 - Performance Review -> Performance Review -> All" (Image below).

• Click New to create a new record. Use any values you like for the required fields.

• Right-click on the form header, then click Save.

The first section of the Record stores standard ServiceNow record information:

• Number, Created, Active

• Assigned Employee and Manager

• Essential data related to executing the Performance Review process

The section "Self Review" stores the fields related to the employee's self-review.

The section "Manager Review" stores the fields related to the manager's part of the review.

The section "Notes" includes any further feedback from the manager and Work notes.

1.4 (Optional) Review the other views

The hamburger menu at the top allows you to navigate to the other views made for this record. This isn't necessary for the lab but adds context to how many attempts there have been at cleaning up this form.

• "Edit Settings" - Exposed fields related to the scheduling of Performance Reviews

• "Emp Mgr feedback" - An old form view used on the original Service Portal view for Managers

• "Manager Review" - A new and cleaner view used for the Manager's review

• "Self Review" - An old form view used on the original Service Portal view for Employees

• "Self Review WS" - A new and cleaner view used for the Manager's review

• "Workspace" - A similar view to the Default view used for a Workspace Experience

Exercise Conclusion:

Through time and process ownership changes; this app has had some interesting design choices that led to this point. We've all been there; apps evolve over time, and the end state is not always a utopia. Though we may be tempted to scrap it and start from scratch, let's see what we can do to give the existing app the makeover it needs.

2.1.1 Open the Employee's Self-Review Playbook

As an admin, on a Performance Review record, you should see the "Related Links" section at the bottom of the form.

Click "Open Employee Review Playbook ↗" to open the Playbook within the Performance Review Workspace.

2.1.2 Review the Playbook

The first stage of the Playbook is "Confirmation." This stage ensures that the Employee is on the correct record before continuing.

Click the "Mark complete" button at the bottom of the Activity to continue to the next Stage, "Looking back."

After marking the last Activity in each Stage as complete, the Playbook will automatically move the user to the next Stage. Conditions can be defined if some activities are optional or driven by selected values.

The next stage, "Looking back" includes three activities. Each activity stores a single field from the "Looking back" section of the Performance Review form.

Add a response for each question and click the "Update" button to save your progress.

Once you've completed all three activities, click "Mark Complete" to save your progress and move to the next step.

2.1.3 Complete the Playbook

Consider the difference between these activities and the prior one in the "Confirmation" Stage. Why would storing each question (field) within a unique activity be helpful instead of grouping them?

The final stage, "Submit," is an automated activity that will update the record's Stage field to Submitted. In the step 2.2 How to open App Engine Studio (AES), you will look under the hood of the Playbook's configuration.

(Optional) Review the UI Action's code

If you're interested in how the UI Action generates a redirect URL, navigate back to the record, right-click on the UI Action, and click "Edit UI Action." The code builds a URL that matches the required and optional parameters for the Workspace Playbook Page Variant template.

The necessary parameters are:

• The table, x_1310421_ccl127_0_performance_review

• The record's sys_id current.sys_id

• (optional) Playbook experience sys_id playbookExperienceSysId

• (optional) Playbook id

This code may be helpful during our challenge section.

Summary

A Playbook is an intuitive way to collect information and trigger automation via a single pane of glass that guides a user through their unique part of a process. Let's look at a working example with our Performance Review application.

For those interested, here's official documentation explaining Playbooks and Process Automation Designer (PAD): https://docs.servicenow.com/csh?topicname=process-automation-designer.html&version=latest

We will use App Engine Studio to work with the Playbook editor for this lab. To navigate to this lab's application, please open the App Engine Studio: "All -> App Engine -> App Engine Studio ↗".

In "My Apps" open the lab's application, "CCL1270 - Performance Review."

Below is an example image of what the AES homepage will look like for your lab.

When ready, continue to the next segment to open and review the Employee's Self-Review Playbook config.

Summary

Do you have a complex intake form that intimidates your users? Or a self-service process requiring specific input to reach the next stage? These are the perfect use cases for playbooks!

You can also bring that step-by-step guided experience to users who only interact with Service Portals!, aka those who ned it most! Bring the ease of guided forms to users who aren't in full UIB Experiences.

DJ and Carleen will guide you through Playbook basics and best practices. You will get hands-on experience configuring and testing Playbooks to revamp an example application that is long overdue for a makeover.

Lab Objectives

By the end of this lab, you will:

• Understand the flexibility of Playbooks.

• Understand when to use Playbooks.

• Learn how to use the Process Automation Designer (PAD).

• Modifying, testing, and publishing a Playbook.

Scenario

In this lab, you will develop a Playbook experience for your company's Performance Review scoped application.

Background

Several years ago, your company created a scoped application to schedule Performance Reviews for employees and managers.

A single table stores the data attributes for each Performance Review: the schedule details, employee self-review, and the manager's feedback. This has created a sticky situation where the form is too complicated to manage and not user-friendly for employees and managers.

The previous development team started to develop Playbooks to create a friendly and easy-to-use fulfillment experience. Unfortunately, the dev team won the lottery and disappeared without forwarding contact info. This is where you come in; we had better get you up to speed.

Resources to get started

2.3.1 Open the Playbook

Navigate to the "Logic and automation" tab from the app's homepage.

Using the search bar on the right, search for "Employee Performance Review."

Clicking on the record to open the Playbook viewer in a new tab.

Select the "Board view" from the toggle in the top center. This view will display each Stage of the playbook as columns (or lanes) and activities as the cards within each stage.

2.3.2 Review the "Confirmation" Activity

Click the card for '1.1 Performance Review' to open the configuration panel on the right-hand side.

• The "Details" tab allows you to configure display information, such as the Label and Description.

• The "Automation" tab allows you to configure logic to apply when an activity, such as "Submit Self Review," is completed.

UI Layout options

• The "Associated Record" section queries a given table for a specific record to pull its fields for use below.

• The "Details" section includes information that will be placed below the activity header. All fields added to this section will be read-only.

• The "Form" section allows selecting a specific form view to control what fields to display. While this may be similar to the "Details" section above, the fulfiller can modify these fields.

In '1.1 Performance Review', notice that the "Form fields" option has 14 fields manually added. These are all the fields displayed within the activity.

Click the pencil icon to the right of the "Form fields" input to view all the fields selected from the associated record.

This time, we are only here to look; proceed to the next step by clicking "Cancel" until you return to the Board view of the Playbook.

If you click "OK" or "Save and close," don't worry. Playbook changes are published via the "Activate" button at the top right, meaning your change won't be reflected until activated.

2.3.3 Review a Question Activity

All of the activities (excluding the last) are a "User form" activity (more on this in the next exercise), so you don't need to review each activity unless you wish to.

Open any question activity and view the UI Layout and Form field selected to see how an activity is mapped to a single field within the form.

2.3.4 Review the "Submit Self Review" activity

The final activity within the Playbook, "5.1 Submit Self Review" is an "Automated Update Record" activity. Aptly named, this type of activity updates an existing record. When this activity runs, it will immediately mark itself as complete and continue executing the process.

Navigate to the "Automation" tab of the activity to view what field is updated via this activity.

For the existing process, when "Status" equals "Submitted," the Employee has completed their self-review, and the system will notify the manager to complete their part of the review.

In review, you have completed the following:

1. Understand how to open the Employee's Self-Review Playbook

2. How to open App Engine Studio

3. How to open the Playbook editor via AES

4. Understand basic Playbook fundamentals (Stages, Activities)

5. Understand how to configure a playbook activity

Now, you're ready to build a new playbook!

Remember, when "Status" equals "Submitted," the Employee has completed their self-review, and the system will notify the manager to complete their part of the review. The previous development team! It's time to build them one.

In this exercise, you will put your knowledge to the test and build the Manager's Review as a new Playbook experience. Below are some recommended tabs to have open while completing this task.

1. An example Performance Review record

   • This will be useful to quickly reference what fields are necessary for the manager to complete.

   • If you've closed the record from Exercise 1, here are two ways you can open one:

     1. Navigating to the Record through the platform via filter navigation. If needed, review Exercise 1: Understand the Performance Review application.

     2. You can also open the record in AES by going to the "Data" tab, and opening the "Performance Review" table. The table should open with the "Data" tab, but you can navigate to it if it didn't. Open any record using navigation icon to the right of the trash-can.

2. The Employee's Performance Review Playbook

   1. It's a great reference for how the similar activities will be configured. If needed, review Exercise 2: Playbook fundamentals.

3.3.1 Navigate to the "Test" button

With your process displayed, click "Test" on the top right-hand corner of the Process Automation Designer.

You will then be prompted to select a record to test against. Select a record of your choice. We recommend you open the record in another tab so you can double-check that Manager-related fields get updated as expected. Select "Run Test" to begin generating your Playbook test-instance.

Now, you will be prompted to preview the playbook. Ensure the dropdown to the right is set to "Performance Review," as this includes the necessary buttons to complete the Playbook. Click the lower "View" button to preview your playbook and open it in a new tab.

After navigating to the Playbook Preview, attempt to complete your Stages and Activities. If any issues occur, note them to fix, and review the prior exercises to see if you missed any steps in configuring your Activities. To retest your Playbook, repeat the steps above to reopen the Playbook preview.

If you wish to further configure the Playbook Preview or if you selected the incorrect Playbook Experience, select the purple gear icon at the bottom right.

You can cycle between records, playbook experiences (not recommended), and activity views. By default, they will be stacked, as in the Workspace experience. However, feel free to view how the playbook can be visually adjusted.

Upon successfully testing your Playbook and having ALL necessary fields get updated as expected, you're ready to move forward with officially activating your Playbook.

3.4.1 Navigate to the "Activate" button

Your Playbook will be "Inactive" unless you have clicked the "Activate" button. To determine what state your Playbook is in, look at the highlight value to the right your Playbook's name.

While inactive, the Playbook won't trigger for any record, even if the Trigger conditions are true. To activate this Playbook, click the "Activate" button and wait for the "Inactive" flag to change from "Inactive" to "Activating" to "Active".

You can now Trigger your playbook based on the conditions you provided:

• If you chose to trigger on Create, then create a new Performance Review record.

• If you chose to trigger on Update and when Status changes to "Submitted" then complete the a an Employee Self-Review Playbook (This may need to be done on a new Performance Review record).

3.4.2 Confirm your Playbook triggered

To confirm if your Playbook was triggered and generated, you can view today's executions via the filter navigation in Platform. Navigate to "All -> Process Automation -> Flow Administration -> Today's Executions" to view the list of all active flow that were generated today.

It's recommended to sort by created to get the most recent records first. If you see one with the name "manager_review" then your trigger was successful. If you don't see it, then confirm if you activated your Playbook, and also review your Trigger conditions. It's recommended that Triggers be retested on new records. Remember to test and activate after changes!

3.2.1 Add Stages

Your empty playbook needs stages (columns) where your activities can reside! Select the "+ Add Stage" to add Stages to your Playbook.

Consider what Stages to add. It's a good practice to show the user what they are about to complete with a "Confirmation" Stage. This stage is usually a read-only summary of essential fields. Aside from this, you should consider your Stages sections of a Form, with activities being fields within the form. Or, you could have one stage, with each activity being a section within the form. Either works, but consider the following:

• How many Stages should you have?

• How many fields should be included in each activity?

Our example displays each Stage as a section from the Manager's Review tab of the Performance Review form. You may follow along or build the Manager's Playbook as you see fit.

When adding a Stage, you will be prompted to select a "Start rule," which will set the conditions for when a Stage is unlocked for the user to open. You can either have the stage start when the Playbook starts or after a prior stage. The first Stage must start when the process starts. Consider the following:

• Should you let all stages start when the process starts, allowing the fulfiller (the manager) to jump between stages?

• Should you let every stage start after its prior stage to ensure a completion flow is felt?

As you'll see, there needs to be a specifically correct answer to most of these questions. As you build, try to imagine yourself as one of the process users as you design your layout.

3.2.2 Add "User form" Activities

The bulk of this Playbook is the fulfiller completing fields within the Performance Review record, so the "User form" activity will be your best bet to display those fields.

Within a Stage, select "Add activity" to view the popover of all available Activities. Navigate to "Common Activities / Default / User Form" to create a User Form activity.

As you set up each Activity, give an appropriate label and description (optional) within each stage (ie. Question #1, Work performance, etc.). Similar to Stages, there is a "Start rule" which defaults to "When stage starts" for the first activity and "After specific activities" for all activities after the first. Consider the same questions prompted earlier about when and what should be available to the fulfiller upon arriving at a Stage.

For most User Form activities for this lab, the "Automation" tab can be skipped. However, it is important to configure the "UI Layout" with the appropriate settings to display the correct record and field(s). If you need a refresher on what should be set, review Exercise 2: Playbook fundamentals, or look at similar activities within the Employee's playbook.

If you're unsure of what fields to add for the Manager's Review, open a Performance Review Record and view the fields that fall within the "Manager's Review" tab, view, or section (depending on what view you have opened). For your convenience, below are the fields grouped by section:

Work Performance

• Works to full potential

• Work consistency

• Independent work

• Group work

• Client relations

Work Traits

• Productivity

• Takes initiative

• Dependability

• Honesty

• Creativity

Feedback

• If applicable, has the employee achieved their goals from previous review?

• What should the work towards for next review?

• Any additional thoughts or feedback?

Optional/Notes:

• Manager Feedback

3.2.3 Add "Automated Update Record" Activity

Once you've filled your Playbook with the user form activities and stages, you'll want the Playbook to finalize the Performance Review and set its Status to "Confirmed." This can be achieved with an "Automated Update Record" activity.

Unlike the "User Form" Activity, the "Automated Update Record" activity will update the record without any fulfiller interaction once the fulfiller has reached the activity. Generally, putting this in the last Stage will ensure the fulfiller is automatically sent to this activity, reducing the chance of it going un-run.

To add this activity, select "Add activity" to view a popover of all available Activities. Then, navigate to "Common Activities / Non-Interactive / Automated Update Record" to create a User Form activity.

Similar to the User Form Activity, the "Details" tab is mostly the same, and the additional fields are listed below with short explanations; however, they can be ignored for this lab:

• Display order: Define the order in which this activity will appear during runtime

• Start with delay: When the start rule is met, wait for a duration of time before running

• Restart rules: Define how this activity runs when restarted. Activity can only restart when conditions are met.

Unlike the User Form, you will need to configure the "Automation" tab with the table, record, and field(s) to update.

For the Record, select the pill-selector, then navigate "Trigger - Performance Review -> Performance Review Record" to select the Trigger record to be updated; this should auto-populate the Table input with the "Performance Review" table.

For the Field inputs, determine which field(s) should be updated. At a minimum, we recommend updating the Status to "Confirmed," but you could also update the "Manager confirmation" field to True.

In the next step, we will test the Playbook you just created!

4.1.1 Prep

This UI Action is going to be very similar to the UI Action to allow Employees, so we recommend you have it open (or even insert and stay on the record).

4.1.2 Properties

This UI Action should be a Form Link and only shown on Update since the Playbook won't be triggered until the record is at least created. We'll update the conditions to further narrow the scope of when and to whom the link is shown.

The condition may be challenging to read, so we'll break it up below to dissect.

(gs.hasRole("admin") || 
current.manager == gs.getUserID()) && 
sn_playbook.PlaybookExperience.parentRecordContainsPlaybook(current)

First, we only want to display the link to admins OR users who are the same as those in the manager field. Then, we also want to ensure that at least one Playbook exists for the given record. The parentRecordContainsPlaybook() determines if a given GlideRecord has at least one associated Playbook return True/False, making an excellent function for conditions. We'll narrow down this search with the Script.

Within the script, we use getPlaybooksForParentRecord() to get a list of Playbooks linked to the given record.

For more information on the Scoped PlaybookExperience API, here is a link to the latest Documentation: https://docs.servicenow.com/csh?topicname=PlaybookExperienceScopedAPI.html&version=latest

Within the script, we loop over the output of getPlaybooksForParentRecord() to determine which Playbook should be added to the URL as the Selected Playbook. If the title field of any object within the array of Playbooks matches the name, you assign it to the Manager Review, which is Playbook, to add using its playbook_id field. Once you've completed this, save and open a Record with the Manger Review Playbook triggering. If needed, review Exercise 3.4 to determine how to do this.

If successful, you should now be able to navigate to the Manger Review Playbook via the link on the Performance Review form.

By the end of this exercise you have completed the following:

1. Understand how to create a new Playbook with App Engine Studio

2. How to open and configure Playbook Triggers, Stages, and Activities

3. How to test a Playbook

4. How to Activate Playbooks

You've officially completed the core portion of this lab. Congratulations! If you're interested in additional challenge exercises, continue on!

By the end of this lab, you have completed the following:

1. Learned the basics of Playbooks

2. Created your own Playbook

3. Configured Playbook Triggers, Stages, and Activities

4. Learned how to add automated steps to your Playbooks

5. Learned how to test and activate Playbooks

Thank you so much for your time and participation; we really appreciate it! We hope you gained to useful knowledge, or at least enjoyed the show. Have a great time a K24!

By the end of this exercise, you have completed the following:

1. Understand how to create a new redirect URL from a Record to its playbook

2. Understand the basics and use cases for the PlaybookExperience API

With this knowledge, consider where else you may want to provide a link to the Playbook.

• Service Portal widgets,

• Emails and other notifications,

• Info messages

• and more...

The following are optional exercises if you finish early or wish to continue with the lab. Navigate to the next sections to begin.

3.1.1 Add a Process

Within the AES' "App Home" tab, navigate to the "Logic and automation" section.

Click the "+ Add" button and select "Process".

Select "Begin" and you will be prompted to the provide a "Name" and "Description".

• Name: "Manager Review"

• Description: "Manager's review of an Employee's Performance Review record."

Select "Continue" when complete.

3.1.2 Select a Trigger

A Trigger is a set of conditions that cause a unique Playbook instance to be generated and attached to a record.

The "Trigger type" is a general field that indicates whether the trigger occurs when the Record is created or updated. Take a moment to consider what trigger conditions should be set for this Playbook.

• Should the Playbook trigger when the Performance Review is created?

• Should the Playbook trigger when a specific field (i.e., Status) is set to a particular value?

Either of the suggestions above would work, but for this example, we'll be using a trigger for when the Record's Status field is updated to "Submitted." Upon selecting "Record Update," the trigger will open a condition builder for the "Trigger condition," which will be set to "Status" "is" "Submitted".

Another setting will appear labeled "Run my trigger". This setting is used to determine how many times a Playbook can trigger for a single Record.

• Once: Triggers the playbook once for the life of the triggering input record.

• For each unique change: Triggers the playbook for every unique update to a non-system field, even if the flow is currently running.

• Only if not currently running: Triggers the playbook for every unique change, but only if a process execution is not already running.

• For every update: This triggers the playbook every time the input record is updated, regardless of whether there have already been or currently are any running process executions.

Given that the manager would only ever need to complete one Playbook for this Record, we will select the "Once" option.

Your playbook will be created upon completing this form. This lab uses screenshots from the "board view," but you may use the view you are comfortable with.