A database stores data. MinistryPlatform goes beyond this by managing the actions that need to take place when data is added or edited. You have the opportunity to define those actions and, when appropriate, indicate the individual users to perform the actions. This means that the folks submitting data don’t need to know what will happen; instead, the Platform checks the workflow rules to see what needs to be done.
Workflow in MinistryPlatform is a set of actions that need to happen when information is added or edited in MinistryPlatform. You define these actions which flow in a linear fashion.
Workflow is made up of the following:
A Process is a planned course of action that is called upon when certain conditions are met in relation to one record on one page. For example, processing a new Group Inquiry or approving an Event.
These are specific actions that make up a single process. For example, as part of the Group Inquiry process, one step may be sending an email to someone who submitted the inquiry. Steps can cause the following actions to take place:
When a change to a record invokes a process, a submission task is created. This happens when a record is updated (or created) and matches the criteria set in an active Process. (See Special Considerations: Submission below.) The User will be prompted to submit the record to the Process when the record is saved.
In order for any workflow steps to take place, a record has to be submitted to a Process. This happens either when it's edited in the Platform and submitted by a user, or when it's edited by the API and automatically submitted.
Upon saving the record, the User will be prompted to submit the record to the Process. They can click Submit to Submit the Process, which will complete the Submit Task. Or, they can click Cancel to submit later, and the Submit Task will then remain for the User to complete later.
Submission is required when a record meets the conditions specified in the Trigger Fields and Dependent Condition settings in the Process.
Changes to a record may invoke more than one Process. A page may be associated with more than one active Process.
Every step in a process will also be associated with a Task. When the Process is submitted, the system will create a Task for the first step and wait until it is completed. The system will repeat this until all Tasks are completed, an Approval Step is rejected, or Processes are restarted. This is how the Process tracks which steps are complete and which one is currently in progress.
A Task can also be created using the Assign A Task Step-Type. Completing the Task moves the Process forward in the workflow.
In the My Tasks tab on the Home page, all open tasks assigned to you are listed. Approval, Submission, and Assigned Tasks have an attached record you can navigate to using the Edit Task dialog.
When a Task associated with a record is not complete, the indicator remains yellow. This is true for Tasks created via a Process or when a User has associated one manually.
A red status indicates an associated Task has been rejected. See "Summary" and the videos below for more information.
If you create several records and want to submit them for approval en masse (rather than one at a time):
Approval is required when a Process has a Get Approval Step defined. The Approval button displays in the toolbar above the record.
If your Process is improperly configured and the Process encounters an error, the Process workflow will still submit data changes and may create or alter records. Please contact your SPoCs for questions or concerns with configuration settings or issues.
It is important to note that If you have a filtered page, keep in mind that workflow processes are table-specific. The workflow Process must be on the table that users are using to create records for the process to fire.
If records are created outside of the platform (in the portal, for example), the generic, unfiltered page is always used.
Any fields that begin with an underscore are read-only in the Platform. They can be updated by Processes, but not directly edited. Since they cannot be directly edited, they cannot be used as Trigger Fields.
Read-only fields begin with an underscore. This includes hidden fields (which begin with double-underscore).
If you want to respond when information is missing, this requires special handling (such as a stored procedure to check for complex data relationships and a SQL agent job to run the stored procedure on a set schedule). If this is what you are looking for, you may want to contact Professional Services to talk through your project.
As an overview, here is a quick summary of the information provided above.
Anytime a record is added or edited in MinistryPlatform, the system checks to see if the record qualifies for a workflow Process. If it does:
0:09 - Gathering the Needed Information
1:40 - The Process Record
2:56 - Adding Steps
4:33 - Testing the Process
0:13 - The Main Page for the Process
1:24 - The Steps Sub Page
2:08 - Testing the Process