Symantec® ServiceDesk Customization Guide 7.0
28
z
“Thank you” page after submitting a Knowledge Base article suggestion
(SD.Feeder.KnowledgeBase)
z
Login failure form (SD.LoginFailureForm)
Many of these pages are found in the “feeder” Symantec Workflow projects, where
information is initially submitted. Most exist as Terminating Form Builder components.
The example to demonstrate this modifies the “thank you” page presented to end-users
after submitting an incident.
To modify the confirmation page upon submitting an incident:
1. In Symantec Workflow, open the SD.Feeder.GeneralIncidentSubmitForm project.
2. Double-click the “Thank You” Terminating Form Builder component, found at the
bottom of the model. This opens the Web Form Editor.
3. By default, two variables are included in the form content, the incident ID variable
and the variable containing the URL to track the incident. You can add more
variables as desired by dragging and dropping them onto the Editor screen from the
Variables list in the lower left.
4. To edit the text in the form, simply double-click the text component and modify the
content of the Text field.
Adding Data to Forms
Adding data to forms requires two steps:
1. Adding the new data to the respective data type, therefore enabling the variable
that houses the data to exist. For example, adding CostCenter attribute to the
Incident data type.
2. Adding the field to the form so the data can be captured. For example, creating a
“cost center” input field for technicians to enter a cost center when submitting an
incident.
Step #1 is a very important, more technical, piece. Both of these steps are covered in
the section
Extend Data/Profiles
(page 46).
Note about removing data from forms:
Use caution when removing components from a form, as output variables designated by
these components will no longer be valid after the removal. For example, if a textbox
component gathers data designated as “ReasonforRequest” and it is removed, anywhere
in the remainder of the process where “ReasonforRequest” is intended to be pulled and
displayed will initiate an error and essentially the process will be broken. A best practice
true of any process is to disable components rather than remove.
Additional Form Customization
Additional form customization examples include adding more sophisticated form data
validation, marking/unmarking required fields, and setting up custom events
surrounding form fields.
An example of custom validation is found in the SD.Feeder.GeneralIncidentSubmtiForm
project, in the “Create New Incident” Form Builder component, in the entry field for
“Who does this issue affect?” Double-click that textbox component and scroll down to
the Validation section to see the custom validation in place. The validation model in this
