Agent scripts add powerful functionality to workspaces and workflows, leading staff members through a series of pages to help them enter information in a logical progression. Script pages can contain most fields and controls available to workspaces, with the exception of relationship items.

They can also include questions and branching logic, similar to guides, so you can create wizards to guide staff members to different pages based on the information entered or actions taken on a previous page. Combining branching logic with page layout capabilities, agent scripting provides your staff with a methodical, efficient interface for capturing information and resolving issues.

To further extend the efficiency provided by scripts, you can add script rules. Like workspace rules, script rules are triggered by events and conditions to perform actions on script pages, such as setting the value of a field or calling a named event.

Before you can create or access agent scripts, you first need to update your profile to include scripting permission. Staff members with scripting permission included in their profile can create, copy, and delete scripts from the Scripts explorer, as well as add them to workspaces and workflows.

Listed next to each script’s name is its script type, based on the type of record it is used to update. The script type determines which fields and controls can be added to the script. RightNow CX provides the following standard script types: Answer, Chat, Contact, Incident, Opportunity, Organization, Task. In addition, you can create scripts for custom objects that have Object is Available in Workspaces, Scripting, and Workflow field visibility. Scripts are not available for use in quote, quote product, or multi-edit workspaces.

Creating and editing scripts

Scripts are created on a script designer consisting of a design space, a ribbon, and a page selector. You define a script by dragging and dropping fields and controls from the ribbon onto the design space and arranging them as you want them to appear on the script page.

When you create a new script page, the design space consists of three areas – a header and a footer shared by all pages, and a main area for content specific to the page. You can add fields and controls to any of these areas.

You can also right-click an item on the design space to access contextual menu options. The available options vary based on the item you right-click but generally include such actions as branching to a page, resetting tab indexes, or deleting the item.

If you delete a script that is used in a workspace, the workspace will still include the Script control. You will need to edit the workspace to remove the control or select a new script for the control.

If you save changes to a script that staff members might be using at the moment, it is a good idea to have them log out and then log back in to be sure your changes have been applied.

If your script has only one page, you cannot remove it. When you remove a page with other pages branching off it, those pages are also removed. When you remove an item used by a rule or branch, the rule or branch will likely be impacted, and you will need to edit or delete it. When you remove a branch used to access a page, the page is not removed. However, this can result in an orphaned page if the deleted branch provided the only path to the page.

Headers and footers can contain any of the fields or controls you can add to script pages. Unlike the content you add to other areas of a page, which is displayed only on that page, the content you add to the header and footer is shown on every page where the header and footer is displayed.

The navigation panel contains 4 buttons that let you navigate between pages in the script even if there are no branches to the pages. Some of the buttons can be used in the When condition in branches and script rules, so you can create your own functionality for these buttons.

Since these buttons are available in a single control, you can quickly add the buttons to any page you want. The page footer contains this control by default. The following buttons are included in the control.

• Beginning: Click this button to return to the first page of the script.
• Previous: Click this button to return to the previous page in the script.
• Next: Click this button to proceed to the next page in the script. By default, this is the next page that is on the same tree level, shown on the page selector, as the current page. However, a branch can be created to load a different page when this button is clicked.
• Exit/Finish: Click this button to trigger any rules or branches that include the Exit Script Event Fires or Finish Script Event Fires triggers. When you are on the last page of a script, the Exit button is renamed Finish. This button is not enabled unless a rule or branch is configured to use one of these conditions.

Adding branches to scripts

Scripts use branching logic for guiding agents to specific pages based on conditions you specify. You can also create branches that are triggered when different responses are selected from question controls, such as the Radio Question or Menu Question controls, or from the Next, Exit, and Finish buttons on the navigation panel.

You can create branches quickly by right-clicking fields and controls on the design space. You can also define more complex branches using the Add Branch window.

Script rules

You can create script rules to trigger actions on script pages when the conditions you specify are met. For example, you can create a rule that automatically sets the value of a field on a script page when a button on the page is clicked or when the page is opened. Script rules impact only the script pages the rules are created on.

However, using named events, you can use script rules in conjunction with workspace rules to trigger an action on a workspace. For example, a workspace rule that sets the incident workspace’s Status field to Solved can be triggered when a staff member clicks a button on a script page.

Script rules, workspace rules, and workflow connectors can be triggered by actions taken by staff members, such as changing a field value or saving a record. However, they can also be triggered by other rules using rule-defined events. Events are defined by adding event fire actions, which vary by event type.

• Named Event: Named events are defined by adding the Fire a Named Event action to a script rule or workspace rule and specifying a name for the event.
• Exit Script Event: Exit script events are defined by adding the Fire Exit Script Event action to a script rule.
• Finish Script Event: Finish script events are defined by adding the Fire Finish Script Event action to a script rule.

Scripts can be exported as XML files and then imported to other interfaces.