Define Process Start and End
Start events are flow elements that define the starting point of a process. Different types of start events determine how process instances are created. End events, in contrast, define the end point of a process. Different types of end events determine what happens when the process instance is completed.
Note:
In Process, all business processes must have at least one start and one end event.Because start events define the beginning of a process, they don’t have incoming sequence flows. Likewise, end events don’t have outgoing sequence flows. However, except for none start and end events, start and end events can have input to and output from other business processes and services.
Specify the Start and End Events for Different Types of Processes
When you create a new business process, a start event and an end event is created by default. The following table shows the default start and end events depending on the type of process you want to create.
| Process Type | Default Start and End Events |
|---|---|
| None | None start and end event |
| Form | Form start and None end event |
| Document | Document start and None end event |
| Folder | Folder start and None end event |
| Message | Message start and end event |
To learn more, read about the different types of business processes supported by Process.
Subprocesses contain none start and end events by default. These are the required start and end events and can’t be changed. See Work with Subprocesses.
Use Multiple Start and End Events in a Process
You can define multiple start points in a business process. Multiple start points allow you to specify multiple ways of creating a process instance, depending on which start event is used. Using multiple start events lets you have multiple ways of starting a process without having to create two separate processes.
End events mark the end of a process path. When you have only one end event in your process and the token reaches the end event, the process is stopped.
Note:
Message end events can only be used to terminate processes initiated by a message start event. Additionally, if you have multiple message end events associated with a message start event, each of these message end events must have the same quantity and type of output arguments.When using multiple end events, it’s possible for different tokens to take different paths within a process. In typical cases, all parallel paths must reach an end event before the process is completed.
However, in the following special cases, a process instance can be stopped before all process paths have completed:
-
Error end event: When an error end event is reached, all process activity is stopped. Like the error throw event, the error end event stops the flow of a process.
-
Terminate end event: The terminate end event causes all work on a process to stop immediately. No error handling or other cleanup of the running process is performed.
About the None Start Event
Use the none start event when no instance trigger is specifically defined. The none start event can be used as a placeholder when the required start event of a process is unknown, not yet defined, or implemented later by process developers.
None start events also specify the beginning of a process where the process instance is created by another flow element. In general, the none start event doesn’t trigger a new process instance.
However, when used with a receive task, the none start event can trigger a new process instance. The receive task must have the Create Instance property set to True.
Similar to other start events, the none start event can’t have incoming sequence flows. It can only have default out-going sequence flows.
Note:
None start events are always used to define the beginning of subprocesses.The none start event doesn’t accept process input arguments.
About the Form Start Event
The form start event triggers a process instance when a user submits a form. The form is specified in the implementation for the form start event.
The form is designed to get input from the user and present information relevant to the workflow. As you build the form, a business object is created to store the form data.
About the Document Start Event
The document start event triggers a process instance when document details are received.
The document start event has a defined list of parameters, such as the document ID, type (where “d” stands for document), and document name, that you save in data objects to read the document metadata.
"id": "document-id",
"type": "d",
"docName": "document-name",
"startedBy": "user Id",
"role": "contributor"See Create a Document- or Folder-Initiated Process. You can also use REST APIs to instantiate a process instance and provide all input values.
Similar to other start events, the document start event can’t have incoming sequence flows. Document Start events require a default outgoing sequence flow.
About the Folder Start Event
The folder start event triggers a process instance when folder details are received.
The folder start event has a defined list of parameters, such as the folder ID, type (where “f” stands for folder), and folder name, that you save in data objects to read the folder metadata.
"id": "folder-id",
"type": "f",
"docName": "folder-name",
"startedBy": "user Id",
"role": "contributor"See Create a Document- or Folder-Initiated Process. You then use REST APIs to instantiate a process instance and provide all input values.
Similar to other start events, the folder start event can’t have incoming sequence flows. Folder start events require a default outgoing sequence flow.
About the Message Start Event
The message start event triggers a process instance when a message is received. This message can be sent from another business process or from a service.
Messages are types of data used to exchange information between processes. Just as data objects are used to define the data used within an application, messages are used to define the data used between processes or between a process and a service.
Similar to other start events, the message start event can’t have incoming sequence flows. Message start events require a default outgoing sequence flow.
You can expose a business process as a service that allows other processes and applications to invoke the process. To expose a process as a service, your process must begin with a message start event. Additionally, you must define the input arguments to the process, which are the data objects passed to the message start event.
The message start event allows you to specify input and output arguments to a process. These arguments define the message that other processes or services must send to the process during invocation. See Defining Input or Output Arguments.
For a business use case, you can invoke a process from any WebService client, such as a SOAP user interface.
To invoke a process using a WSDL:
-
Go to the Home page, click Processes, and create an application using the Start Message Event.
-
Activate the applications and go to the Management page.
-
From the list of activated application, select the application you just deployed.
-
Click Actions and select WebService.
-
Copy the url displayed in the Exposed Webservice tab.
-
Open a third party WebService client, for example, the SOAP UI,
-
Create a new project, enter a Project Name and enter the copied url in the Initial WSDL field, and then click OK.
-
Click Start Operations and create a basic authorization.
-
Enter the Username and Password for authorization.
-
Click the Play button on the top.
The process is invoked.
About the None End Event
The none end event marks the end of a process path. When a token reaches a none end event, it’s consumed. If there are no other tokens within the process instance, then the instance is complete.
Use the none end event:
-
When your process isn’t required to perform any action after it completes
-
To always mark the end of a subprocess
-
As a placeholder to be changed later during implementation by a process developer
For example, in a Sales Quote business process, the Sales Quote service task saves information about the sales quote to a database. Because no other work can be performed when the token reaches the end of a process, a none end event is used. After all process tokens reach the none end event, the process instance completes.
About the Message End Event
Use the message end event to send a message to another process or service when the process is completed.
You always use the message end event with either a message start event or message catch event.
When creating a process that has multiple end events, make sure that any tokens that reach a message end event were created by a message start event. For example, you can’t use a message end event to end a process instance initiated by a form start event.
Want to learn more about how to configure output arguments using message end events? See Defining Input or Output Arguments.
About the Error End Event
Use the error end event when the end of a process is the result of an error condition.
You typically use the error end event with the error boundary event. The error boundary event is used to change the process flow based on a specific error. This flow usually ends with an error end event. See About the Error Boundary Event.
The terminate end event causes all work on a process to stop immediately. No error handling or other cleanup of the running process is performed.