About CtrlProcesses
CtrlProcesses has three parts that share one connection to Elements.cloud and are otherwise independent: a synchronisation that brings processes into the vault, a viewer that draws them inside M-Files, and a publisher that sends links back the other way.
What comes in
Section titled “What comes in”The synchronisation runs on a schedule and creates M-Files objects for what it finds in Elements.cloud. Seven kinds of thing come across, each mapped to an object type, a class and a set of properties you choose:
| From Elements.cloud | What it is |
|---|---|
| Releases | A published version of a set of process maps |
| Process maps | A map, holding diagrams |
| Process diagrams | One diagram within a map |
| Activities | A box on a diagram, including its RASCI roles |
| Resources | People, systems and other things an activity uses |
| Reference models | A standard or framework a process is mapped against |
| Reference model nodes | An individual clause or requirement within one |
Objects are matched by the Elements.cloud id, stored in a text property on the M-Files object. That is what makes a second run update the object it created last time rather than making another one, so the property has to be set on every mapping and must not be edited by hand.
What goes back
Section titled “What goes back”URL publishing works in the other direction. When an object enters a workflow state you have configured, CtrlProcesses publishes a link to it in Elements.cloud, with a description and any tags you have mapped. Entering a retire state removes it.
The published link’s id is stored back on the M-Files object, so a later version updates the existing link rather than creating a duplicate.
This is what closes the loop: a procedure approved in M-Files appears against the activity it governs, for people working in Elements.cloud rather than in the vault.
The viewer
Section titled “The viewer”The viewer is a tab on the M-Files object, showing the Elements diagram for whatever that object relates to.
Which diagram comes from the object click mappings: a mapping says that an object of a given class opens a particular diagram, reading the diagram id either from the object itself or from an object it refers to. Where that object is a process activity, the viewer also centres the diagram on the activity and marks it.
Which version of the diagram is the setting worth understanding before anything else.
What a user can do in it is per user group. A mapping gives each group its own set of viewer features and the diagram it opens first; the mapping marked default covers everyone else.
What is drawn on the boxes comes from two more lists. Activity status lights score an activity from a data table attached to it and show the result as a traffic light. Reference model flags colour an activity that maps to a standard you care about — and that list is also the opt-in, so a reference model with no entry is not flagged at all.
Authentication
Section titled “Authentication”Elements.cloud is reached with two sets of credentials.
The system context is used by the scheduled synchronisation and anything else running in the background. The end-user context is used for operations done on behalf of the signed-in user, so that what a person sees and does in the viewer is attributed to them.
Both are configured, and both have to work: the viewer failing while the synchronisation succeeds usually means only one of the two has been filled in.
Pacing and rate limits
Section titled “Pacing and rate limits”The synchronisation talks to an API that rate-limits. It handles that itself: when Elements returns a rate-limit response it slows down and then speeds back up again.
Two settings bound that behaviour. Minimum request interval is a floor it will not go below — leave it at zero unless your tenant has a known limit, because it is not a delay to add to every call. Maximum retry wait is a budget for the total time one run may spend waiting. When the budget is spent the run stops early and reports it, and the next run resumes the sections it did not finish, so nothing is lost.
Deletion
Section titled “Deletion”Objects whose Elements.cloud counterpart no longer exists are handled by a separate reconcile operation with its own schedule, and what it does to them is configurable. It is separate from the synchronisation on purpose: deleting is the irreversible half, and running it less often than the import is the safer arrangement.
With no schedule triggers configured, neither the synchronisation nor the reconcile runs automatically — including at application startup.
What it does not do
Section titled “What it does not do”- It does not edit processes. Everything flows out of Elements.cloud. Changing an M-Files object created by the synchronisation does not change the process, and the next run may overwrite it.
- It does not replace Elements.cloud. The viewer draws diagrams; the mapping is still done in Elements.
- It does not synchronise files. Documents stay in M-Files; only links to them are published.