Step Types
Last updated
Was this helpful?
Last updated
Was this helpful?
When initialized, an Action Step sends a notification to the assigned actor(s) to complete a task defined in SSP 7. The assigned task can be defined in a request form linked to the Action step within SSP 7. The completion of this form will close the Action Step and initialize the next step within the Process work flow.
An Action Step is added by clicking on in the Edit Steps tab of a process and defining the step type as an Action step.
Click on the title 'Form' to define the Form for the Actor.
When an Action Step is activated the Actor receives an email with a link to SSP 7. Clicking the link will open the Action Step Form consisting of required and/or optional fields. When Actor completes all the required fields, the action step is closed and the process continues to the next step in the work flow.
The Action Step form is built using the Action Step Formbuilder. This Formbuilder is similar to the end-user Formbuilder ( see ) with the certain limitation. The following list describes the limitations:
List of available simple fields are limited to : Text Field, Text Area, Radio Button (yes/no), Upload File, Upload multiple files, Date Field, Date & Time field, Numeric field, Rating field, External form.
List of available Selection fields are limited to : Drop-down, Checkboxes, Radiobuttons, Cascading drop-down, Listbox (single or multiple selection), Searchable listbox (single or multiple selection).
No Sections or headers can be added.
These Input Masks can be applied to text - based fields: All - Email - Url - Regular expression
No filters can be applied on selection fields
Default answers & help texts can be set
The Form section displays a list of all current Fields, and includes the option to create a new Field.
The columns present in the form table are:
Label: The Label of the default language.
Type: The selected type of the Field.
Required: check if required, no image if not required.
Order: Set the order of the Fields.
Action: Delete & Edit a Field.
Available options in this page:
Live on Website: Mark this option to show this field in the form.
Required: Mark this option if value must be entered in this field.
Searchable via Search Tickets : allow this field to be searchable when the user does a ticket-search. Limit the number of fields, for performance reasons.
Type: Select the field type (described above).
Width: Field width can be defined here if necessary. This is expressed in characters.
Translations: Label: Define the field name in English and other languages as set in SSP 7.
Translations: Help text: Add any help text in English and other languages as set in SSP 7 that will be displayed at mouse over the field title in the form.
Rating field: This is a special process-only field. When this field is selected the user will see stars that can be clicked. The number of stars is defined in the 'Width'-field.
External form: This option makes use of the full capability of regular forms with sections, HTML and hidden fields. When this option is selected the form will appear in a ticket as a pop-up window when a button is clicked. Once the form is submitted and no additional fields are in the step, the step is automatically submitted.
When an external form is selected, the option "Use values from previous entry as default values" is possible. This option can be used in case the ticket is rerouted to the step with the external form. If this option is not checked, the external form pops up blank. When this is checked the data entered the first time around is shown in the form.
When the underlying form is edited, these changes are carried over the live tickets, so the changes are visible for all open tickets as well.
Sending date from the process to the subform can be done using Process Variables. Data from the form that started the ticket, can be referred in the external form by using 'Base Form values'.
For details on using the Formbuilder refer to the Formbuilder for End-user forms. Follow this guide but be aware of the limitations as previously described in this section.
Another type of step is an Approval Step.
This step sends an email to an Actor for approval. The approval by the Actor is given by completing 2 predefined approval fields in the SSP 7 approval form:
The following are the approval form fields:
Decision, showing 2 options : 'I accept' & 'I decline', presented in radio buttons
Comments : text area, required in case of decline.
Other possible actions:
An Approval step can be compared to an Action step, but with these key differences:
A 'Declined' notification email is sent when the Actor rejects the request.
When the Actor rejects the request the ticket will be closed.
When there are more than 1 approver defined, the number of approvers required for an overall approval needs to be set.
Click on the title 'Form' to define the Form for the Actor.
In the case of an 'Approval Step', the options are limited.
By default, SSP will present 2 fields:
- Decision
- Comments
The 'Decision' field will always show 2 options : I approve & I decline. These can not be changed.
The 'Comments' field however, can be changed. By default, is is a test area field, that only becomes required when the decision is negative ('I decline').
Click on the EDIT icon to change the settings of this field.
These are the options:
The checkbox for required - status can not be changed, as this field will always become required when the decision is negative.
- Type : simple fields
Select Text field or Text Area
- Type : Selection Fields
Select any of the types that are presented.
We refer to the details of an Action step to learn about details of each field type.
Click on the title 'Decline Email' to define Email template for the Decline Email. This email is sent to the Requester when this Step is not approved by the Actor(s).
A sub-process step allows to run a process within a process, wait for its execution and then continue with the main process. This step type is useful when a sizeable part of several processes is the same - say the approval part, or when a process can exist on its own or be part of a larger process - e.g. a computer request can stand on its own or can be part of an on-boarding process.
In this section, a process can be selected to be part of the main process. When that is done, all fields of all steps in the sub-process appear and each field can be automatically filled with values from a main process step or be left blank.
There are three parts to this section.
This is where the process is selected to be used in the main process. To view the selected process details an edit button is available next to the drop-down.
Here all fields from the steps appear. Each field in each step in the sub-process can be automatically filled with values from the main process. For example in the above example, the first step in the sub-process is an approval step. If the approval in the sub-process is the same as the approval from the main process (for example both require the line manager's approval but it doesn't make sense to have the manager approve the request twice) then the sub-process approval step can be automatically filled and submitted from the main process. The decision field will match the decision of the approver from the main process approval step, and the comments will match the comments from the same approval step in the main process.
Or the third field is "Group name" which is a free text field. Again, the value of this field can be defined from the main process or can be left blank and the actor of step "Pick actor" will fill in the required information.
In the second set of fields all other information can be defined from the main process. For example, in the above example, the first such information is Email (Email approvers) / this field appears in Step "test" and also as a condition in the decision step "test DP". If the actor of step "test" needs to be defined from the main process, this can be done by matching that field to an actor definable from the main process. Otherwise, if left blank, the actor will be defined from the sub-process.
The other field in this section from our example is Name(addorremove). The Context explains that this field appear several times in the Step Information (otherwise known as Translation) of the step "Approval from Tim". This can also be defined from the main process or if left blank, the original definition will be used.
End of sub-process
When the sub-process is completed, the main process continues. All steps of the sub-process are also shown as part of the main process. To the end user it is not obvious that several processes have been used to handle a ticket.
When a process is added to a process as a sub-process, its steps become part of the main process. The steps and all information provided in or related to a sub-process step are handled the same way as any other step within the process.
For example, information provided in a sub-process step can be used in other steps or decisions as "previously entered field". When a step canceled, it behaves the same way as a main process step. When the ticket is closed, so is the sub-process.
A Decision Point allows you to define alternate workflow paths within a process.
A Decision Point serves only as a switch and therefore no emails or Actors are defined.
This following diagram is an example of a decision point within a workflow path.
This process has the following steps:
- Notification 1: An email sent to the Requester ( for example). This step only sends out the email to the Actor, and requires no interaction from the Actor. This step is then closed and the process continues to step 2.
- Approval 1: This step requires an approval ( I accept / I decline ) from the Actor. If the approval is declined, required comments are added and the ticket is closed and a decline email is sent to the Requester. If an approval is received, the process continues to step 3.
- Notification 2: An email is sent to the Actor with the appropriate notification information and the process continues to the next step.
- Decision Point 1: This step will define if the process proceeds to Approval 2a or Approval 2b. Regardless of the determined path, the process will continue to the next step, Notification 3.
- Notification 3: This is the final notification after which the process is completed and the ticket is closed.
Click on the title 'Decision Step' to define the alternate Paths.
Evaluate at start : when checked it will evaluate the paths at ticket start and false paths will not be copied into the ticket, so they can never become active. When you are 100% sure that the value can not be changed during the runtime of a ticket, we advise to check this box. It will result in a decrease of database size, as SSP does not need to copy over all possible steps in the blueprint.
There are 3 possible types of Decision Steps, changing between them will clear al the detailed settings for the previously selected Decision Step.
Normal: Based on previously entered fields in a related form or from within the process, paths can be defined.
Approval Step: Used specifically for an Approval Step. A path can be created for approved or declined approval results.
Multiplier Step : This Decision Type needs to follow a Repeater step, containing a Decision. This point defines what happens after a Repeated approval, in various possible scenarios.
Connector Step : The Decision Point looks at the outcome of a Connector step (for example to BMC)
This type of Decision Point allows you to freely set as many paths as you want, based on form Fields or data that is entered previously in this Process. The other types of Decision Points (Approval & Multiplier) can only be inserted after either an Approval or a Multiplier Step.
Workflow Paths can now be added to the decision step.
To build a Row, follow these steps:
Source : The first field determines the source value for which the rule in the Row will be built. The available Source selections are as follows:
Previously Entered Field : A value entered in one of the form prior to this Step, in the same Process.
Lookup : A value entered in any of the forms.
Process Information : Information regarding the process
Variable : a process variable
Value from webservice call : as defined in a previous step
Ticket field : Any field from the Ticketing module
2. Data field : When the source (first drop down) is selected, the next drop down field will be updated with corresponding source data. Complete the second drop down. Please select the correct data field that will be compared against the benchmark ( final field).
For example, if 'Lookup' is selected in the first fields ('source'), this list will show all Forms in SSP.
3. Item selection : select the wanted 'data'-element from the list. This list is filtered against the selected 'data field'
For example, if a Form is selected in field 2 ('Data field'), the list of FIelds of that selected Form are shown in this selection list.
4. Connector: Select the correct operator for the selected value and benchmark. Available operators are =, <, <=, >, >=, != (different), begins/ends with, contains, does not begins/ends with, does not contains
5. Benchmark: This is used in the Row definition to compare against the selected data field.
It can either by a 'Fixed value', that is entered in the text box. Or it is a 'Dynamic value', created based on the same sources as the first part of the condition.
Else - Path
If a Path has no Rows, it is considered as 'Else', so it will take all other options, if not met by any of the previous Paths' Rows. If you insert an 'Else' Path, please do so as the last Path. If you put it first, it will take all tickets and not look at the other Paths anymore.
Adding multiple Rows in a Path
Multiple Rows can be added to Paths to define additional conditions. The possible connectors are :
- AND - OR - AND NOT - OR NOT
Please note that nested conditions are not possible, and 'AND' conditions will overrule 'OR' conditions.
For example, this rule setup :
Row 1 & 2 will be looked at together, and Row 3 stands alone.
This means that these settings are valid for this Path:
- brown & 1 ( Rows 1 & 2 are valid)
- any color & 2 (because Row 3 is valid)
In the example above, if the administrator wanted to only allow the combinations 'brown & 1' and 'brown & 2', the setup above will not work. We advise to split thus in 2 Decision Points.
Simultaneous Paths
SSP supports multiple Paths that are started at the same time. If the Rows for Path 1 a Path 2 are both valid, both Paths will start. The only exception is an 'Else' Path, without any Rows. Once an 'Else' Path is found, going through the Paths from top to bottom, SSP will stop looking at the Paths after the 'Else' Path. So always put the 'Else' Path as last.
Example
This following sample shows a Decision Step containing two paths, each of which having one Row:
Viewing the Decision Step in Steps Overview
The Decision Steps in the Steps Overview is displayed as follows.
The Decision step has a title of "D" in the step.
The two paths are displayed side by side separated by a dotted line. The Paths are merged by adding a Step outside the blue box.
"Approval Step" Decision Points contain two predefined non-editable paths specifically used for inserting after Approval Steps. Similar to Normal type Decision Points, Approval Step Type contain paths with rows as shown in the following diagram.
Approval Step Decision points are predefined to contain 4 Paths containing one row that can't be edited. Each path defining a work flow for approved, declined and time-out. This Approval Step Decision type is used to quickly add an approval decision to a process work flow and to capture declines within approvals. In case a decision step is defined on an approval step, the decline email will no longer be sent by the approval step, but should be manually defined within the Declined path of this decision step.
The Approval Decision Steps in the Steps Overview is displayed as follows.
The Decision step has a title of "D" in the step.
"Multiplier" Decision Points contain several predefined non-editable paths specifically used for linking to Multiplier Steps. Similar to Normal type Decision Points, the Repeater Type contain paths with rows.
A typical example of a Multiplier Decision Point is folder approval. A User can request access to multiple shared folders at the same time. Each folder has its own designated approver. In the Multiplier step the approval is multiplied by x times, where x represents the number of folders that are requested.
The Repeater Decision Step will allow you to define distinct paths for possible outcomes from the Multiplier step. For example, the following are possible outcomes for folder access example.
- All approved: Initiate Decision Path 1
- Partially Approved ( minimum 1): Initiate Decision Path 2
- Declined : Initiate Decision Path 3
Similar to Normal type Decision Points, Approval Type contain paths with rows as shown in the following diagram.
The three Paths, each containing one Row, are pre-defined and can not only be removed, not edited. You see that the three standard decisions of an Multiplier Approval Step are presented, each defining a seperate path.
This setup is non-editable, its sole purpose is to allow you to quickly make a Decision point, based on an Repeated Approval, where the outcome is always one of the 3.
2 more paths are added as well, to handle Time-outs & Interruptions:
The Multiplier Decision Steps in the Steps Overview is displayed as follows.
First, the Multiplier Step is indicated by the yellow box with the title "M"(position 1). Following the multiplier step indicator is the detailed multiplied step.
This Decision step is inserted after the multiplied step (Row 2). Decision steps have the title "D" in the step.
Additional steps can be added to each Path.
The Decision Paths are merged by adding a Step outside the blue box. The overall process will only continue when all multiplier processes have come to an end.
This type of Decision Point looks at the outcome of a previous step, of the type 'Connector'.
Select the Step and SSP will present 2 paths:
- Approved
- Declined
With the Execute Application step, external programs can be triggered by SSP 7 and parameters can be provided to these applications.
Click on the title 'Application Settings' to define how the external application should be triggered.
Location: Set the full path and name of the executable in this field. Please make sure the user running the IIS service is entitled to execute this application.
Parameters: Provide the parameters that are given to the external application. This parameter string can be a combination of fixed text and values coming from the process or Forms.
The Http Request Step is used to communicate with another web service within the network.
Click on the title `Http Request Settings` to define
Method
URL : Define the URL where the web service is located and add parameters to this URL by making use of dynamic values.
HTTP headers
This step type allows to perform an internal SSP action, like managing members of a Group.
Click on the title 'General Settings' to define the General Settings for this Step.
Type : Select 'Internal action'
Action : Select the internal Action that you want to perform when this step is started. Options are:
Add person to person group
Remove person from person group
When the action 'Add person to person group' is selected, this box comes up:
When you manually add a Person to a group, you need some basic information. This is also requested here:
- Person group : the name of the group
- Person : the unique ID of the person to be added
- Receive emails : contains 'yes' if the newly added person is to receive emails sent to this group.
When the action 'Remove person from person group' is selected, this box comes up:
When you manually add a Person to a group, you need some basic information. This is also requested here:
- Person group : the name of the group
- Person : the unique ID of the person to be removed from that group
With the Jump step, a forced jump to any step in the process can be defined. This step is particularly convenient for creating a controlled loop in the process.
Click on the title 'General Settings' to define the General Settings for this Step.
Jump to step : Select the next step where the process should continue.
to be completed
A Multiplier Step allows you to repeat the same step inside a process.
A typical example is folder approval. A user can request access to multiple shared folders at the same time with each folder has its own designated approver. In the Multiplier step, the approval is multiplied by x times, where x represents the number of folders that are requested.
A Multiplier Point serves only as a switch and therefore no emails or Actors are defined.
This following diagram is an example of a multiplier point within a workflow path.
This process has the following steps:
- Notification 1 : An email sent to the Requester ( for example). This step only sends out the email to the Actor, and requires no interaction from the Actor. This step is then closed and the process continues to step 2.
- Multiplier 1 : This step will multiply the next step by the amount of Actors for the next step.
- Approval 1a to Approval 1c : This step is repeated, based on the criteria set in the Multiplier step above.
- Notification 2: Final notification, and the process is completed, so the ticket is closed.
To create a Multiplier Point, follow these guidelines:
Click on the title 'Multiplier Step' to define the field that will be used to determine the number of times the following step(s) are repeated. Only 1 field can be selected.
The Multiplier Step section is as follows.
The following fields define the values to be used for the Multiplier step.
Lookup first drop down menu : Select the Form. You can choose any Form from SSP 7, but be ensured that this Form is linked to this Process.
Lookup second drop down menu : Select the field from the list of fields of the chosen form above. Only fields that are linked to a Parameter in the Datastore can be selected (selection fields). These fields have pre-defined possible answers, allowing rules to be built. This is impossible with free-text answers.
The Multiplier Step in the Steps Overview is displayed as follows.
The Multiplier Step is indicated by the yellow box (position 2). In the yellow-bordered box below, the step that is multiplied is indicated.
This step is used for sending an email notification to the Actor. This step involves no additional input and therefore is closed as soon as it is completed.
Using this step, you can edit the contents of a variable using a step in the process. This is very useful to for example change a Status-variable on given points in the process.
Whenever a variable is looking at a formfield, and the original request gets changed by an actor, there is no need to implement this step.
Click on the title 'Variable Settings' to define what needs to happen in this step.
Variable : Select a variable from the list. Only variables from the process that you are editing can be selected.
Value - Contains calculations : Check this box if you want to perform calculations (NCALC) in this step
Value : Enter the value that you want to update
When the General Settings have been set correctly, it is possible to let SSP 7 generate signed documents with your corporate DocuSign signature.
Any PDF document available within a workflow, can be signed by DocuSign. In the example below, a PDF document is generate by SSP 7, signed and sent by email.
Define a PDF Report within your process.
Include a step in your process of the type "Sign documents via DocuSign".
Ignore all settings with respect to reminders, messaging and Escalation. Open the section with header "Sign documents via DocuSign settings"
Open the section with header "Initial email" to compose the content of the email that should be sent.
Now set who should receive the signed document(s) by going to the Actor Settings header.
The SM7 Adapter Step is used to communicate with the Service Manager 7 Application. By making use of this step a new Interaction, Incident, Change or Task can be created. In order to use this step, the license for the SM-connector needs to be acquired.
- Create Interaction: With this method new Interactions can be created.
- Create Incident : With this method new Incidents can be created.
- Create Change : With this method new Changes can be created.
- Create Task : With this method new Tasks can be created.
- Update Interaction: With this method new Interactions can be updated.
- Update Incident : With this method new Incidents can be updated.
- Update Change : With this method new Changes can be updated.
- Update Task : With this method new Tasks can be updated.
With the Stop step, a forced stop in the process can be defined. This step is particularly convenient for stopping a process when a certain situation has occurred. Depending on the settings of this Stop step, either the complete ticket or a path is stopped.
Action : Select the action. These options are available:
Close ticket : Stop the complete ticket
Stop decision path : top the current decision path (that holds this Stop step). The process will continue with the first step after the Decision path.
Stop multiplier branch : Stop this instance of the multiplier. The other branches (coming from the same multiplier) will not be stopped.
Decision : set the Decision (approved or declined) when this step stops the ticket, path or branch.
To be completed
The Wait-step allows to halt the process. You can define conditions for the process to leave the Wait step and continue the flow. The Wait step can be used in combination with external adapter steps, variables values, relative or absolute dates, ... The step can for example be used to wait for the completion of a ticket created in an earlier process step.
Click on the title `Wait Step` to define the condition for ending the wait step. Once the condition set here becomes true, the wait step will be completed and the next process step is activated.
Exclude from Wait Steps : when checked this wait step will not be processed via the Check Wait Steps task, so another service will trigger the check wait steps check. In this case, the 'Wait'-step is not actively checking the value himself, but is waiting for an external trigger. Once the external trigger completed the action, the Wait step will continue directly, without the need to wait for the Scheduler to kick-off the task to check all Wait-steps.
Row 01 : Select the Type and complete the details. The different types are explained in the next pages.
Multiple Conditions : In case multiple fields are required to check, choose the AddCondition-button. An additional line for the definition of a new condition is displayed. Select how these conditions should be combined to each other by setting the Connector.
Task definition : In order to make the wait step work, a task should be defined. This task will be triggered by the Scheduler and will do the checks for pending wait steps every time it gets triggered. Please note that if the wait step task has a refresh rate of 15 minutes, the check if a wait step matches the conditions set, is done every 15 minutes.
Wait for external value: With this option, you can set the Wait step the check the external system is a selected value has reached a set value.
Wait until a fixed date: This type is simple: select a fixed date, and the Wait step will block the process until that date.
Wait prev. entered field: Wait until date entered at a previously entered field.
wait lookupfield: Wait until date entered in a form field
Wait relative: Wait for relative amount of time, from a step.
wait date variable: Wait for a date, set in a Variable.
Wait ext value webservice: Wait for external value from webservice call.
Wait ticket field: With this option, you can set the Wait step the check if the SSP ticketing system value has reached a set value.
Wait variable value: With this option, you can set the Wait step the check if a selected Variable has reached a set value.
Months
Days (all calendar days, so including weekends & holidays)
Business days (excluding week-ends (saturday-sunday))
Hours
Minutes
It is possible to update a parameter in SSP from a process. The process takes the information from a form and the Webservice Call updates the selected parameter(s) and its fields.
There are 3 options available - add, update or delete. Therefore, the parameters in SSP are dynamic, can be modified without administrative rights and can facilitate workflows.
Examples of when the Webservice Call can be used:
List maintenance:
There is a list of approvers and the list needs to be updated usually one or two entries at a time.
Add or remove items from any parameter.
Create custom lists of job description with worker health and safety items, attach them to an employee and retain this information for future comparisons. Update any part at any time.
Budget calculations:
A department's training budget is distributed among several managers. A parameter stores the total budget, the allocated amount per manager. When an employee requests a training, the approvers and coordinators can see how much the (remaining) total budget is, how much the training costs and once the request is approved and the training completed, the numbers are updated in the parameter.
A company's real estate management with lease agreements and dates is managed via SSP. Costs, deadlines and other information can be updated via a form and stored in a parameter.
In the process, add a step of the kind "Webservice Call".
All fields in the webservice will appear.
The fields will appear below. Add the data coming from the form that will be used to update each field.
The information for each field can come from either the form, or from a parameter value.
The XCBL connector is very specific to connect to cXML interfaces, like Dell is using.
Please contact us to set up a connection protocol using cXML.
Delegate: by clicking the icon, the Actor may delegate his task to one of his defined under My Profile.
Request additional info: by clicking theicon, the Actor may request additional clarification from the requestor.
Custom actions that are defined under
The approval form can't be customized. The approval form will always consist of a decision and comments field. In case more fields are required, please make use of an .
An Approval Step is added by clicking on in the Edit Steps tab of a process and defining the step type as an Approval step.
A Decision Step is added by clicking on in the Edit Steps tab of a process and defining the step type as a Decision step.
Changing the Decision Type will result in a total loss of entered Paths for this Decision step!
Select "Normal" as Type in the selection box & click on.
Changing the Type, will result in a total loss of entered Paths for this Decision step!
Click on to add the first entry.
Paths are deleted by clicking on the button for the Path.
Next, Rows are added to each Path to define the conditions required to activate the path. Click on to add a Row.
Use the button to save the changes, or use the button to discard any changes.
This type of Decision Point only works when inserted after an Approval Step. When this is not inserted, the next Steps for an Approval step, in case of decline are limited to closing the ticket. With a Decision Point, of the type Approval, you can specify another work flow in case of Decline. Select "Approval Step" as Type in the selection box & click on .
Changing the Type, will result in a total loss of entered Paths for this Decision step !
Use the button to save the changes, or use the button to discard any changes.
The 4 paths are displayed side by side separated by a dotted line. The Decision Paths are merged by adding a Step outside the blue box. The time-out path is followed in case the time has been reached. The Interrupted path is reached when the ticket is interrupted. 'Interrupt' is a Step Action that can be added.
Select "Multiplier" as Type in the selection box & click on.
Changing the Type, will result in a total loss of entered Paths for this Decision step !
Use the button to save the changes, or use the button to discard any changes.
The Repeater decision step is followed by 5 different paths arranged in a row separated by a dotted line. Each path represent the possible combination of outcomes for the multiplied step. The time-out path is followed in case the time has been reached. The Interrupted path is reached when the ticket is interrupted. 'Interrupt' is a Step Action that can be added.
An Execute Application Step is added by clicking on in the Edit Steps tab of a process and defining the step type as an Execute Application step.
Please note that this step should be used with care. All steps are available to jump to, however steps further down in the process may not be available as destination step, as the process step is not yet activated, or is missing data to get activated.
Do not jump from an active path into another path of the same or different Decision Point. This can confuse SSP, as maybe other paths are still active within the same Decision Point.
A Jump Step is added by clicking on in the Edit Steps tab of a process and defining the step type as an Jump step.
On the Edit Steps tab of a process, click on . The Step Details screen appears.
For any step within the Multiplier box, the selection of the Actors is very specific! You need to select Actors of the type 'Multiplier Step'. If not, all Actors will have rights to all instances of the multiplied step !
Use the button to save the changes, or use the button to discard any changes.
A Notification Step is added by clicking on in the Edit Steps tab of a process and defining the new step type as a Notification Step.
In the field labeled "Value", set a reference to the PDF document you want to have signed. For example:
Method: Select the action to be performed by the adapter. Choose before you continue.
A Stop Step is added by clicking on in the Edit Steps tab of a process and defining the step type as an Stop step.
An Wait Step is added by clicking on in the Edit Steps tab of a process and defining the step type as an Wait Step.
You can add Additional time, expressed in:
To set up a Webservice call, first a Webservice must be configured. For details, see the section on under Adapters.
Under Webservice Call select the Webservice that you will use, and Click
Select the ones that will be used in this process and click
When done, click
SSP supports the CXML standards, initiated by Ariba. More information:
