The actual model is of course more complex than the image shown on the content page An introduction to Power Process because of the mentioned design goals on that content page.

Below, a logical view of Power Process is given.

Before the model is described in more detail, a few topics are described first.

Locations

Power Process consists of 5 locations:

  • The trigger
  • The orchestrator and central storage
  • The dispatcher
  • Activities
  • The activity queue

, connected through cloud flows (Microsoft Power Automate).

Push / Pull cloud flows

Power Process consists of several Power Automate cloud flows. The amount of cloud flows depends on the amount of activities.

Cloud flows are always related to a location. Some cloud flows will pull data (read) from another location and store it locally while other cloud flows push data (create) from its location to another location.

Manual / Automated activities

An activity is not always a manual activity. Power Process is designed such that automated activities are possible too. Meaning that activities can be completed without human interaction.

Local actions

The orchestrator only pulls data from (#2, #8), and pushes data to (#3, #9), other locations. The dispatcher only pushes data to other locations (#3). The activity queue only pushes data to the central storage (#7).

Other actions must be done locally. Examples of local actions are the creation of data, setting permissions and sending notifications.

Data duplication

Security is a key objective for Power Process. Someone must therefore only be able to access data (s)he is allowed to. This will result in (temporary) data duplication.


Detailed description

A process instance always starts in the trigger location and consists of 2 or more activities. There are always at least 2 activities because starting and ending a process instance are considered to be an activity too.

Activities are grouped in process steps where each process step can consist of 1 or multiple parallel activities. Only when all activities in a step are completed, the process instance can proceed to a next step. Starting a process instance and ending a process instance are considered their own process step. Consequently, a process instance also contains at least 2 process steps.

The logical view is described in more detail below.

#1 – Push data to the orchestrator

The trigger is the start of a process instance and at a certain moment, a trigger flow (#1) writes a record in the central storage. Only the following data is written:

  • An unique ID for the instance – called the instance ID.
  • A status.
  • The process version.

This setup allows for a quick response from the cloud flow to a canvas app starting the trigger flow.

#2 – Pull data from the trigger

Based on the instance ID, data is pulled from the trigger by the orchestrator flow (#2) and stored in the central storage.

This setup allows for asynchronous actions such as copying unstructured data (files) from the trigger to the central storage which can take longer than the request time-out limit.

#3 – Push data to the dispatcher

When all data (structured and unstructured) is stored in the central storage (#2 and #8), the next step is determined. This next step along with the instance ID and process version is send to the dispatcher by the orchestrator flow (#3).

No new step will be send to the dispatcher If the ending activity (process step) has been executed.

#4 – Push data to one or multiple activities.

All activities have at least one list called the main list.

The dispatcher flow (#4) creates a record in all main activity lists related to the step to execute. This record contains an unique ID which is called the activity instance ID.

#5 – Pull data from the central storage

All activities have at least one cloud flow, called the main cloud flow. The main cloud flow takes care of local actions like pulling data from the centrale storage (#5).

#6 – Push data to the activity queue.

When an activity is completed, an activity flow (#6) writes a record in the activity queue. Only the following is written:

  • The instance ID.
  • an unique ID for the activity – called the activity ID.
  • an unique ID for the activity instance – called the activity instance ID.
  • The process version.

The activity queue knows which activity ID belongs to which step. This is needed to determine if a step is completed or not.

The activity queue cloud flow allows for only one cloud flow to run at the same time. This is needed to reliable determine if a process step is completed or not.

The activity flow could be the same cloud flow as the main cloud flow for automated activities.

#7 – Push data to the orchestrator

When a process step is completed, the activity queue cloud flow (#7) updates the process instance record in the central storage with a new status.

#8 – Pull data from one or multiple activities

Based on the status, data is pulled from one or multiple activities by the orchestrator flow (#8) and stored in the central storage.

#9 – Push data to the trigger

Data is pushed to the trigger by the orchestrator flow (#9) so the person triggering the process instance gets a status update.