Understanding Scripts

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.

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.

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.

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;

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.

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.

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:

1. It adds the weights for all questions in the script.

2. It calculates the weight factor for each question by dividing the weight of the question by the sum of all question weights.

3. It determines the base score for each answer that the respondent gives.

4. It calculates a final score for each answer by multiplying the base score by the question's weight factor.

5. 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.

Script Ratings

Script ratings are text descriptions associated with specific score ranges.