The design goals of the light edition of Power Process are the same as the full edition. There is one main difference between these editions and that is that the setup of the light edition is less complex and therefor easier to grasp and to implement.
This less complex setup does have a consequence: All employees involved in the process can read all process data.
If this consequence is no issue, then it is advised to automate your process with the light edition instead of the full edition. At the bottom of this content page, an implementation variant is described which makes it possible that certain process data can only be read by certain employees.
In general, one can say that the light edition of Power Process has less lists and less canvas apps compared to the full edition. The number of cloud flows is still related to the number of activities and will therefor not differ that much.
This content page has a focus on using SharePoint Online as the data store. When Dataverse is used as the data store, additional security options are possible like field-level security and who is allowed to read which process data.
Below, a logical view of the light edition of Power Process is given.
All main process data is stored in the main list (#1). Besides this main list, normally several additional lists are present (#5). Some will contain master data like generic settings or drop-down values and some lists will contain additional work data.
There is one main canvas app (#2) which is used by all employees involved to start, or act on, process instances. It is advised to use canvas components in this main canvas app to reduce the number of controls.
Data cannot be changed directly from the main canvas app. Cloud flows (#3) are used for this making sure that create, update and delete operations are only possible via the main canvas app and not directly in SharePoint. Changing master data directly in SharePoint is allowed for a small group like functional application managers.
The cloud flows which are triggered from the main canvas app (#3) must be as light-weight as possible so they can return data within the request time-out limit. Therefor, there are many of these cloud flows. Do include error-handling in these cloud flows. This makes the cloud flows a bit less light-weight but it is regarded as a best-practice.
There is a second set of cloud flows which trigger on changes in the main list (#4). This allows for asynchronous automations which can take longer than the request time-out limit.
In practice, the #3 cloud flows are used during, and to end, an activity and the #4 cloud flows are used to act on an activity end.
The logical view is described in more detail below.
#1 – Main list
The main list contains one record per process instance. A record contains all needed properties as well as some system properties like status. A system property is a property that is not directly maintained by an user.
All users involved in the process must only have read access to the main list.
Often, process data can be grouped into parent data and child data. This list contains all parent data. Child data is included in additional lists (#5).
#2 – Main canvas app
The main canvas app is used to
- trigger process instances.
- act on process instances.
- close process instances.
The functionality of the main canvas app is of course very process specific. In general, one can say that it includes the functionality:
- of some simple help information and a link to a location with more extensive help information.
- to start a process instance.
- to act on activities like adding additional work data and approvals.
- overviews like my active forms and all active forms.
- to show all details of a process instance.
- Adding structured data and unstructured data (files).
A professional canvas app is characterized by including error-handling and situations like:
- Detecting a version mismatch.
When in-place archiving is used, the amount of data in lists will grown in time which can – or better will – lead to delegation issues. The main canvas app must therefor only be related to working data. Insights to working data and archived data is achieved via a Power BI report. When the amount of data can surpass the maximum data limit Power BI can handle, in-place archiving must not be used.
#3 – Instant micro cloud flows
This set of cloud flows are triggered from the main canvas app.
Because a cloud flow should give a response the main canvas app as quickly as possible (at least within the request time-out limit), a collection of micro cloud flows must be created. Each micro cloud flow is related to an event in the main canvas app like submitting a form or uploading a file.
Error-handling must be built into the main canvas app to be able to inform the used when an error occurred. The micro cloud flows must therefor respond data which indicates the success/failure of the cloud flow. Logic must be added in the main canvas app to act on this response as well as include the IfError function to handle unexpected error.
#4 – Automated cloud flows
This set of cloud flows are triggered by data changes in the main list.
These cloud flows are asynchronous cloud flows that can run for a longer time of period.
In practice, these cloud flows are used to act on an activity end.
#5 – Supporting and secondary lists
Supporting lists contain master data like generic settings, drop-down values or process specific data like who is involved how in which activity.
Secondary lists contain working data.
All employees involved in the process must only have read access to the supporting and secondary lists.
Technical application management will – by default – have full control access to all data. This does not mean that they should change data in SharePoint directly. Changing data must still be done on a controlled way like putting the business solution is maintenance mode and waiting for the time-out to pass before changing data.
Instant micro cloud flows must be configured that all users related to the process can run these cloud flows.
As with the full edition of Power Process, it is assumed that all users involved in the process have a Microsoft 365 license which allows the usage of Outlook, Power Apps, Power Automate and SharePoint.
It is assumed that the cloud flows run under an automation account. This is an Entra ID account not used by users but created specifically to be the owner of all cloud flows. This automation account must therefor be used for all implementation activities. The automation account always has full control to all data.
Implementation variant – Additional security
In case some process data should not be readable by all users involved in the process, the light edition can be extended with a third set of cloud flows: Instant micro cloud flows where each cloud flow reads data from one supporting or secondary list.
Such a supporting or secondary list must be configured such that no employee has access to it. Because the automation account has access, the user gets access on a controlled way to the data because the canvas app can contain logic who is allowed to run which instant cloud flows of this third set.
Know that for this implementation variant to work, the amount of data that must be returned to the canvas app must be limited.