Phased rollout

 

This version of the software is currently available only to early adopter SaaS customers as the first step in our phased rollout.

Creating questions to use with SRDs

While submitting a service request in the Request Entry console, users must respond to the questions that you mark as mandatory. Data gathered through these questions are used by the fulfilment applications to process the request.

You can add branch conditions to display additional sets of questions, based on their response to a question. When users submit their service request, their responses are passed on to the fulfillment application through the variables specified in the PDT.

Question types and options

You can create questions in the following formats:

  • Text
  • Radio buttons
  • Check boxes
  • Menus (static menu, query menu, or dynamic query menu)
  • Range
  • Date and time (date, time, or date/time)

For information about creating the questions for an SRD, see Defining the questions and Creating menu questions.

You add questions and branch conditions to service request definitions (SRDs) and then map them to AOTs and PDTs. When an application instance occurs, the responses are pushed to the corresponding fields of the application instance form. A user's responses are pushed to the application instance for a particular AOT. See Mapping variables to questions and Mapping service request fields.

Optionally, you can store frequently-used questions in the Questions Library, which you can access from the Application Administration console: Custom Configuration > Service Request Management > Application Configuration > Define Questions Library. When you choose a question from the library to use in an SRD, you are taking a copy of the question for the SRD. This means that any future changes to a question in the Questions Library are not automatically reflected in SRDs that contain the question. You cannot store conditions or dynamic query menu questions in the Questions Library. 

Best practices

Consider the following best practices for creating questions:

  • Ensure that the Question Text (or Display value) that you specify for text, radio button, and check box questions fit into the space allowed in the UI. Because strings of text are wrapped at spaces, we recommend that you consider the length of each word, the word spacing, and the available UI space to make sure that the text wraps properly. When defining questions, make sure that you also consider the length of any localized question text or display values.
  • The internal value for each option in a radio button, check box, or menu question, whether parent or supporting, must be unique within the set of possible answers. We recommend that you use an integer for the internal value so that it can be treated as an enumeration by the back-end fulfillment process, if necessary. Where the response is seen, such as in the Request Details, the display value is shown. The display value can be localized. The internal value must be locale independent and is not localized, even if it is not an integer, so that the fulfillment process can consume it independently of the user’s locale. 
  • Create all of the questions, branch conditions, and mappings in the default locale before localizing the SRD. See Localizing SRDs and surveys.

Restrictions in creating questions

Be aware of the following restrictions before you create questions.

  • Creating required, hidden, or read-only questions — The question requirements must match the data targets you map, as described in Mapping variables to questions. For example, because the Description field is required, the question should be required as well.
    • When the user's answer to a question is pushed to a required variable, specify this question as required. For example, if you want a user to enter the urgency of a change request, make sure to specify that an Urgency question is required.
    • If a user ignores the question and submits the request, the fulfillment application generates an error (which you must troubleshoot later).
    • If you hide the question, the fulfillment process proceeds without requiring any response from the user. 
  • Hidden questions work in the following ways:
    • The question and response are not visible to users, approvers, coordinators, service desk agents, or administrators in the Request Entry console or Request Details.
    • You must enter a default response or use an action to add a response value. If you hide a required question but do not provide a response, an error is displayed when the user tries to submit a request.

    • Do not hide Date/Time, Date, or Time fields.
  • Entering default values — Creating a default value overrides any previously configured defaults.
  • Using HTML markup in questions — HTML markup, such as <b> bold </b> is not supported in question text or response options. 
  • Using special characters in questions — If you want to use the greater than (>) sign, less than (<) sign, or quotation mark (") in a question or response option, use encoded text (&gt for >, &lt for <, and &quot for a quotation mark); otherwise, browsers will interpret these characters as HTML markup, which is not supported.

    Best practice

    For embedding links or URLs, we recommend that you do not embed links or URLs in question text. Instead, use the instruction field if you need to provide links or URLs with questions.

Be careful about the variables that are exposed to users. An attempt to create a work order from the SRD will fail if a user enters the wrong values, for example, if the Priority field in a work order has a value other than Critical, High, Medium, or Low.

Warning

To prevent command automation interface (CAI) mapping errors on text questions, determine the right value to enter in the Limit Input Length field to on the Question Management form. If you are passing the values from a text question from BMC Service Request Management to a fulfillment application (for example, BMC Incident Management), make sure you set the proper field length values. Otherwise, errors might appear in the CAI events trying to create records in the fulfillment applications, because data from one of the fields in the service request is too long (for example, trying to pass 128 characters to a field that only accepts 100 characters).

Was this page helpful? Yes No Submitting... Thank you

Comments