Understanding Scripts
A script is a predefined set of questions or statements that are joined together in a specific order and used to gather information from respondents. At runtime, a questioner follows the script and records the respondent's answers. Actions associated with the script can be performed at specific points during the script. Certain applications, such as Call Center applications, enable self-service users to follow scripts.
This section lists common elements and discusses:
Script building blocks.
Branch scripts and linear scripts.
Questions and question groups.
Script trees.
Answer sets, rules, and rule sets.
Variables and tokens.
Actions and action sets.
PeopleCode functions.
Rate sets and script scoring.
Field or Control |
Definition |
---|---|
<ID> |
Displays a unique identifier for the object. This field is not visible on definition pages; it appears only on search pages. It provides a unique identifier when the object name is not unique. |
![]() |
Click to view or modify the referenced object on the page where it is defined. The page appears in a new browser window. |
Sequence |
Enter a number to order rows of data within a grid. |
To set up a script, define its building blocks in the proper sequence. The following table shows the relationships between script building blocks. The order in which the objects appear provides a possible setup sequence to ensure that all prerequisites are met for each object. You do not necessarily use all objects in every script; you use only the building blocks that support the features that you want to include in the script.
Objects in angle brackets are PeopleTools objects. You define them in PeopleTools rather than on the script pages.
Object |
Can Reference |
Can Be Referenced By |
---|---|---|
PeopleCode function |
<PeopleCode> |
|
Variable |
None |
|
Action |
|
Action set. |
Action set |
Action |
Script (Script and Script Tree pages). |
Token |
|
|
Rule |
Variable |
|
Rule set |
Rule |
Script (Script Tree page). |
Answer set |
|
|
Question |
|
|
Question group |
Question |
Script (Script Tree page) |
Rate set |
None |
Script (Script page) |
Script |
|
None |
Scripts can be either branch scripts, which use conditional logic to determine a sequence of questions, or linear scripts, which contain a fixed set of questions in a fixed order.
In a branch script, a script tree shows hierarchical relationships among questions. Questions are parents of answers, which are in turn parents of follow-up questions. Sibling nodes on the tree represent mutually exclusive paths through the script, so questions that are asked depend on the answers provided.
In a linear script, the script tree hierarchy is flat. Questions are parents of answers, but answers have no children. Instead, all questions appear at the same hierarchical level. All questions are asked, and no branching logic is used.
Image: Branch script tree and linear script tree
This diagram illustrates the difference between a branch script and a linear script.
![Branch script tree and linear script tree](img/i-42c12a96n-7756.png)
Scripts consist of questions that a questioner asks a respondent.
Question Types
Four types of questions exist:
Single selection
The respondent must choose a single answer from a predefined answer set.
When you set up a branch script, you can create branches for each possible answer.
Multiple selection
The respondent can choose multiple answers from a predefined answer set.
When you set up a branch script, you can create branches under each answer, but the questioner follows the branches only when the respondent selects a single answer.
Value input
No predefined answers exist. The questioner enters the respondent's answer as free-form text. The answer is normally assigned to a variable.
You cannot create branching logic after a value input question.
Guide information
Instead of asking a question, the questioner makes a statement. You typically use guides at the end of a script; for example, to thank the respondent, summarize the conversation, or describe the next steps.
You cannot create branching logic after a guide information question.
Question Groups
At runtime, the Script Execution page normally displays one question at a time. This restriction is necessary when you incorporate branching logic based on the answers to the questions.
Sometimes, however, it makes sense to present several questions together. For example, on one page, you might group a series of value input questions for gathering demographic information.
Question groups are sets of questions that appear together at runtime. To define a question group, you identify the questions to include.
You cannot use branching logic with a question group.
You define the flow of the script in a script tree, which provides a hierarchical representation of the questions, question groups, and answers that are used when the script runs.
This section discusses the relationships among the types of nodes in the script tree.
Single Selection Questions
Three types of nodes can follow a single selection question:
Answer nodes
Answer nodes are required for questions that are associated with static answer sets. Each valid answer is a separate node. You do not have to create nodes for all answers in the answer set, but an answer that does not appear as a node cannot be a valid answer.
Rule nodes
Rule nodes follow questions that are associated with dynamic answer sets, but rule nodes are not required for these questions.
Rules are conditions that are expressed as logical statements; if the condition is met, then the statement is true.
In a branch script, rule nodes that follow a question create the branching logic that determines the next question. In a linear script, no branching logic is used. Nevertheless, you can use rule nodes to set up actions that are performed after a question is answered.
Any nodes
In a branch script, you use an Any node for a transition to the next question when no other branch is available. If no rules follow a question with a dynamic answer set, then an Any node must follow the question.
An Any node can coexist with answer nodes and rule nodes; the questioner uses the Any branch when none of the answers or rules for the same question have branches of their own.
In a linear script, which does not use branching logic, an Any node is unnecessary for a single selection question.
Multiple Selection Questions
Two types of nodes can follow a multiple selection question:
Answer nodes
These are the same for multiple selection questions as for single selection questions.
In a branch script, you can include branches for the individual answer nodes. However, if the respondent selects more than one answer, the script follows the Any branch rather than the other branches.
Any nodes
In a branch script, an Any node should appear after a multiple selection answer. The Any node is necessary in case the respondent selects more than one answer. The questioner also follows the Any branch when the respondent selects a single answer if that answer does not have a branch.
In a linear script, which does not use branching logic, an Any node is unnecessary for a multiple selection question.
Value Input Questions
In a branch script, you use an Any node to transition from a value input question to the next question.
In a linear script, a value input question has no child nodes.
Question Groups
Both branch scripts and linear scripts require an Any node for a question group. Without the Any node, the question group displays the questions, but not the possible answers.
Guide Information Questions
Guide information questions are typically the final nodes of branches. They provide a final statement that the questioner uses to end the conversation. Consequently, they have no child nodes. The script does not continue past the guide information question at runtime, even if the question has a child node.
To create a transition from a subscript to a parent script, do not use a guide information question as the final node of a subscript branch. If a subscript branch ends with a guide information question, the system does not return to the parent script when the questioner reaches the end of that subscript branch.
Subscripts
Subscripts are available for branch scripts but not for linear scripts. When you incorporate a subscript into a branch script, you have two options:
Return to the parent script when the subscript is complete.
Use an Any node to create a transition from the final subscript node to the next question. End the subscript branches with answers or rules. Do not end subscript branches with guide information questions, which prevent the system from returning to the parent script.
Do not return to the parent script when the subscript is complete.
Answers, Rules, and Any Nodes
In a branch script, answers, rules, and Any nodes can be followed by questions (of any type), question groups, and subscripts.
In a linear script, answers, rules, and Any nodes do not have any children.
Validation
A script-validation process checks for question groups and questions (other than guide information questions) that do not have child nodes.
Rules are logical statements that support conditional processing for dynamic answer sets.
Static and Dynamic Answer Sets
Answer sets provide a list of valid answers to a question. There are two types of answer sets:
Static
Static answer sets have a fixed list of possible answers. The same set of answers appears regardless of how the respondent answers other questions.
If a question has a static answer set, when you place the answer set in a script, you can include some or all of the answers in the set as possible answers. Each answer that you include becomes an answer node in the script tree.
Each of those answer nodes forms a new tree branch that can have its own follow-up question. (You can insert an Any node into the tree, so that the Any branch is followed if the respondent selects an answer without its own follow-up question.)
Dynamic
Dynamic answer sets use PeopleCode functions to generate a list of valid answers. Dynamic answer sets can be associated with a single PeopleCode function or, if they are associated with multiple PeopleCode functions, they can apply rules to determine which function to use.
PeopleCode Functions Used in Dynamic Answer Sets
PeopleCode functions that generate a dynamic list of answers must follow these guidelines:
They must not have any input parameters.
If the function needs to refer to the script's parent component, it can use the &cmpExecKeyRec component variable for the parent component.
They must fill an input rowset with the answers.
This rowset record must have at least one key field.
If you support multiple languages, you need two rowset records: one for the base language and one for non-base languages.
They must call the rcInitDyanmicAnswer function in FUNCLIB_SCRIPT.RC_DYNAMIC.
This function reads the values used to fill the rowset and converts them to dynamic answers.
For example, the following PeopleCode function generates a list of products based on a setID that the respondent selects. This is the GetProduct function, which is used in the delivered script called Products.
REM +----------------------------------------------------------+; REM | Determine the value of the SETID variable |; REM +----------------------------------------------------------+; &arSetID = GetVariable(&cmpInstanceREC.RC_BS_INSTANCE.Value, "SETID"); If &arSetID.Len > 0 Then &sSetId = &arSetID[1].SCR_VAR_VALUE.VALUE; end-if; REM +----------------------------------------------------------+; REM | Create the input parameter rowset based on the language |; REM | that the script execution page is using and based on |; REM | input from the user. |; REM +----------------------------------------------------------+; If &cmpInstanceREC.LANGUAGE_CD.Value = "ENG" Then &rsDynamic = CreateRowset(Record.RC_DYNAMIC_PROD); &rsDynamic.Fill("WHERE SETID = :1", &sSetId); else &rsDynamic = CreateRowset(Record.RC_PROD_LNG); &rsDynamic.Fill("WHERE SETID = :1 AND LANGUAGE_CD = :2", &sSetId, &cmpInstanceREC.LANGUAGE_CD.Value); If &rsDynamic.ActiveRowCount = 1 And None(&rsDynamic.GetRow(1).RC_PROD_LNG.SETID.Value) Then &rsDynamic = Null; &rsDynamic = CreateRowset(Record.RC_DYNAMIC_PROD); &rsDynamic.Fill("WHERE SETID = :1", &sSetId); End-If; end-if; REM +----------------------------------------------------------+; REM | Call the rcInitDynamicAnswer function to create |; REM | the dynamic answers |; REM +----------------------------------------------------------+; rcInitDyanmicAnswer(&rsDynamic);
Rules and Rule Sets
Rules are logical statements that can be true or false. When a rule is true, its associated processing occurs. Rule sets are groups of rules. Rules must belong to rule sets in order to be used. Scripts use rules and rule sets in two places:
In a dynamic answer set.
When multiple PeopleCode functions generate answers for a dynamic answer set, you use rules to determine which PeopleCode function to use. The rules and their associated PeopleCode functions are assigned a sequence, and the PeopleCode function associated with the first true rule generates the answer set.
You do not explicitly reference rule sets in answer sets. When you prompt for rules, the values are limited to rules that belong to sets. (The rules referenced in the answer set do not need to belong to the same rule set.)
In the script tree after a question that has a dynamic answer set.
When you build the script tree, the answers generated using a dynamic answer set do not appear as nodes on the tree. Consequently, they are not available for branching. Instead, you use rules to implement branching after a question with a dynamic answer set.
When you click the Add Answer button for a question with a dynamic answer set, the system prompts you to identify a rule set. You then select rules in the rule set and use them as rule nodes on the tree. Each rule node is the start of a new tree branch and has its own follow-up question.
Example of a Dynamic Answer Set
Suppose that you want an answer set that consists of different product names. You sell products under different brand names in different regions, so you need a dynamic answer set that generates different lists of products depending on the respondent's region. You can set up a dynamic answer set with parameters similar to the ones in the following table.
Sequence |
PeopleCode Function |
Rule |
---|---|---|
1 |
GetProducts_West |
Region = West |
2 |
GetProducts_South |
Region = South |
3 |
GetProducts_Midwest |
Region = Midwest |
4 |
GetProducts_Northeast |
Region = Northeast |
Note: This scenario illustrates the use of a dynamic answer set. In practice, you would instead use a PeopleCode function that evaluates the region and derives the product list accordingly.
Two types of variables are used in scripts: standard variables and tokens.
Standard Variables
Standard variables are based on the respondent's answer to a question. (Alternatively, you can use PeopleCode to set the value of a variable.)
Use variables to store answers to questions, so that answers can be referenced later in a script. You can do this to personalize subsequent questions (by referencing the variable from a token), or for processing logic (by referencing the variable from a rule or an action). It is not necessary to use variables for all questions, only to those with answers that you want to reference later in the script.
Tokens
Instead of conditional processing, you can use tokens in questions. For example, a token can represent a respondent's name, so that the questioner can address the respondent by name.
You cannot incorporate tokens into guide text questions.
There are three ways to set a token value:
Use a standard variable.
Use a component interface method.
PeopleSoft provides the RC_TOKEN_CI component interface for creating methods that set a token value. You can use the RC_TOKEN_CI component interface to hold all the code that resolves tokens.
Use a PeopleCode function.
When you use a PeopleCode function to resolve a token, the function must assign a value to the &sNewTokenValue component variable. When the system resolves the token, it runs the PeopleCode function and then uses the value of the &sNewTokenValue variable as the token value.
All PeopleCode functions used in scripts are called from a function-name evaluation program in FUNCLIB_BRSCR.RC_PC_FUNCTION.fieldformula. Because a limited number of PeopleCode functions can be evaluated, use the component interface method to programmatically set token values.
Sample Code for Tokens
The following PeopleCode function can be used when the script's parent component is a case. The function retrieves the case contact's name based on the case ID and business unit. The value is assigned to the &sNewTokenValue variable.
&If &cmpExecKeyRec.Name = "RC_CASE" Then
SQLExec("SELECT A.NAME FROM PS_RD_PERSON_NAME A, PS_RC_CASE B WHERE B.CASE_ID = :1 AND B.BUSINESS_UNIT = :2 AND A.PERSON_ID = B.CASE_CONTACT", &cmpExecKeyRec.CASE_ID.Value, &cmpExecKeyRec.BUSINESS_UNIT.Value, &sNewTokenValue);
End-If;
The next sample uses the component interface method. Note that the value is not assigned to a variable.
Function GetCaseContact() Returns string If &cmpExecKeyRec <> Null Then If &cmpExecKeyRec.Name = "RC_CASE" Then SQLExec("SELECT A.NAME FROM PS_RD_PERSON_NAME A, PS_RC_CASE B WHERE B.CASE_ID = :1 AND B.BUSINESS_UNIT = :2 AND A.PERSON_ID = B.CASE_CONTACT", &cmpExecKeyRec.CASE_ID.Value, &cmpExecKeyRec.BUSINESS_UNIT.Value, &sContact); End-If; End-If; Return &sContact; End-Function;
Use actions in scripts to enable the questioner and the system to perform activities other than asking questions and recording answers. Action sets are groups of actions that are performed at the same time. When you incorporate actions into a script, you must prompt for an action set rather than individual actions.
Action Types
Actions can initiate three types of processes:
PeopleCode (type PeopleCode).
A component interface method (type CI Method).
For example, when a troubleshooting guide provides a successful solution to a case, a component interface action can update the case status. By using a component interface to update the data, you ensure that all applicable component processing occurs.
Transfer to a specified page (type Transfer).
Certain scripts require transfer actions. For example, troubleshooting guides enable support personnel and help desk agents to identify solutions for cases. By setting up a transfer action to the RC_USE_SOLUTION page, a script enables the questioner to review the Solution page and apply it to a case. (The RC_USE_SOLUTION page is delivered specifically for this purpose; it is not available through menu navigation.) For scripts that you make available to self-service users, use the RBT_FAQ_PG_SS page to display solutions.
To use a component interface or transfer action, you must instantiate the keys to the underlying component. When you define the action, you can specify a variable or constant as the key. Alternatively, you can select the Called Component check box to set the key values to the values of the identically named fields in the search record of the script's parent object.
Note: To set up actions, you need to be familiar with PeopleTools object names and other technical features of the system.
Action Runs
Always run actions as part of action sets. You can run an action set in two ways:
Automatically
The system performs the action set when the event occurs.
Manually
The questioner initiates the actions in the action set by clicking a button that appears when the event occurs.
Regardless of whether action sets are run automatically or manually, all actions are run together in a sequence that you specify. Include no more than one transfer action per action set, and make sure that the transfer action occurs last. Once the transfer occurs, subsequent actions do not run.
Action Usage Within Scripts
Actions can be associated with the following events.
Event |
Location to Select the Action Set |
---|---|
A user launches the script. |
On the Script page, in the Pre-Script Action field. |
The questioner leaves the script without reaching the end of a branch. |
On the Script page, in the Incomplete Script Action field. |
The questioner leaves the script after reaching the end of a branch. |
On the Script page, in the Post-Script Action field. |
A question is displayed. |
On the Script Tree page, in the Action Set Name field in the Question Information group box. |
A question is answered. (You can define different actions for different answers.) |
On the Script Tree page, in the Action Set Name field in the Answers grid within the Answer Set Information group box. |
The branch is followed for the first true rule in a rule set. (When there are several rules that are siblings in the tree, the system evaluates them in order and stops after reaching the first true rule.) |
On the Script Tree page, in the Action Set Name field in the Rules grid within the Rule Set Information group box. |
A question group is displayed. |
On the Script Tree page, in the Action Set Name field within the Question Group Information group box. |
You can use PeopleCode functions in scripts to:
Dynamically generate an answer set.
Perform an action.
Set the value of a token.
For the function to run within a script, you need to:
Identify the function on the PeopleCode Function page.
Add function-specific code to the FUNCLIB_BRSCR.RC_PC_FUNCTION.FieldFormula PeopleCode.
When you set up the function on the PeopleCode Function page, you can generate an output file with the code to add to the FUNCLIB_BRSCR.RC_PC_FUNCTION.fieldformula PeopleCode. You can then copy and paste the code from the output file into this PeopleCode program. This requires familiarity with PeopleSoft Application Designer.
Scripts have a scoring system to assign a numerical rating to a set of script responses. Rate sets associate text descriptions with scoring ranges. For example, in a lead qualification script, the score can measure the lead's potential, and the text description might qualify the score as hot, warm, or cold.
Script Scores
The script score is based on the score for each selected answer, as well as the weighting of each question.
The system performs the following steps to determine the overall script score:
It adds the weights for all questions in the script.
It calculates the weight factor for each question by dividing the weight of the question by the sum of all question weights.
It determines the base score for each answer that the respondent gives.
It calculates a final score for each answer by multiplying the base score by the question's weight factor.
It calculates an overall script score by adding the final scores for each answer.
For example, consider a script where the respondent answers six questions. Three questions have a weight of 1, two have a weight of 2, and one has a weight of 3. The total of all the weights is 10 (that is, 1 + 1 + 1 + 2 + 2 + 3 = 10). Therefore, the score for each of the questions with a weight of 1 is multiplied by a weight factor of .1, the score of each of the questions with a weight of 2 is multiplied by a weight factor of .2, and the score of the question with a weight of 3 is multiplied by a weight factor of .3.
This example is illustrated in the following table. The score for the entire survey is the sum of the weighted scores for all questions that the respondent answers.
Question Weight |
Weight Factor |
Answer Score |
Weighted Score |
---|---|---|---|
1 |
1/10 |
10 |
1 |
1 |
1/10 |
10 |
1 |
1 |
1/10 |
20 |
2 |
2 |
2/10 |
20 |
4 |
2 |
2/10 |
30 |
6 |
3 |
3/10 |
30 |
9 |
Total Weight: 10 |
- |
- |
Total Score: 23 |
Script Ratings
Script ratings are text descriptions associated with specific score ranges.