Once the BPM is complete and deployed to the application, the user(s) involved will start a given activity in one of two ways, depending on how the activity is configured:
- Push: The activity will be automatically checked out to the user upon initiation, depending on other properties like the user's security permissions and current workload.
- Pull: The user will search a pool of available activities and check out a specific activity.
Regardless of how the user gets the activity, the basic experience is the same: launching the activity will automatically navigate to the screen the user needs to be on to do the work. The user will create or update whatever data the activity requires, then use a BPM button on the screen to do one of the following:
- Submit: This completes an activity that requires creating or updating data and triggers the next activity (reviewing and approving/rejecting that data).
- Approve: This completes an activity that requires reviewing previously created or updated data.
- Reject: This routes the process to the previous activity, where the data under review was created or updated, so that data can be corrected.
Upon clicking the button, the user is finished with that activity. The activity can be configured so this completes the activity without the user needing to do anything else, or it can be configured to require the user to indicate the activity is complete. The user may do this via a separate activity maintenance screen, or via the left navigation menu controls. Besides completing activities, the user may use either set of controls to cancel, suspend, resume, etc.
Once a process has been assigned to a user (whether because the user pulls it or has it pushed to them), you can trace the specific instance of that execution. Select the desired iteration and open the map to see the process progress. You can continue to do this after the process is complete.
This post is part of the BPM topic. Click here to open the BPM Overview.