About CtrlTeams
A CtrlTeams deployment answers one question: when someone in the organisation starts working in a Microsoft Teams channel, how does that work end up governed by M-Files rather than scattered across Microsoft 365?
Three applications each answer part of it.
CtrlTMS watches Microsoft 365. When a team or channel appears, it creates an M-Files object for it and keeps the object’s members in step with the real thing. It can also work the other way, creating a team in Microsoft 365 from an object in the vault.
PDS puts a known shape inside that team. A project template in M-Files describes the folders a project of that kind should have, and the documents it should start with. PDS turns the template into a set of artefacts ready to be uploaded.
CtrlSync moves the files. From then on it brings the channel’s changes into the vault on each cycle and, where Prevent checkouts is No, sends back a document edited in M-Files when it is checked in. It is the one application that cannot be left out: nothing else moves documents, and PDS sends all its work to Microsoft through it. CtrlTMS talks to Microsoft Graph itself.
Which combinations are supported
Section titled “Which combinations are supported”| Combination | What you get | Where it falls short |
|---|---|---|
| CtrlSync alone | Files in step between the vault and SharePoint or Teams | Someone has to create each connection by hand |
| CtrlSync and CtrlTMS | Teams discovered and tracked automatically, files in step | New teams start empty |
| CtrlSync and PDS | A consistent folder structure and starting documents per project | No automatic discovery of teams |
| All three | A team appears, gets its structure, and starts synchronising | — |
All three together is the deployment these applications are designed around. The two-way combinations are supported and used; nothing in the products prevents them.
What has to be decided before you configure anything
Section titled “What has to be decided before you configure anything”Three vault design decisions are shared across the applications, and all three are awkward to change once objects exist.
Connection objects live on their own
Section titled “Connection objects live on their own”CtrlSync works from connection objects — one per SharePoint site or Teams channel. It is possible to put the connection properties on an object you already have, such as a project, and the applications will work. It is not recommended.
A connection has a life of its own. It moves between workflow states as synchronisation is switched on, pauses and fails, and those transitions have nothing to do with where the project is in its own workflow. Sharing one object between the two means one workflow has to serve both, and neither ends up describing what is actually happening.
The Graph URL is one property, used by three applications
Section titled “The Graph URL is one property, used by three applications”CtrlSync reads the property its Graph URL setting names, on each connection, to know where to synchronise. CtrlTMS writes it, as its Graph URL Property, on the teams and channels it discovers or creates. PDS reads it, as its SharePoint URL Property, and refuses to activate a project until it is filled in. All three settings have to name the same vault property.
The employee property is one property, used by two applications
Section titled “The employee property is one property, used by two applications”CtrlSync’s employee configuration and CtrlTMS’s member configuration both map an M-Files login account to an object representing a person. Point them at the same property on the same object type, or the same user will resolve differently depending on which application is asking.
One Entra registration or three
Section titled “One Entra registration or three”CtrlSync and CtrlTMS both authenticate to Microsoft Graph, and both can use the same Entra ID application registration. That is the recommended arrangement: one registration, one client secret to rotate, one set of admin-consented permissions.
The permissions each application needs are different, so a shared registration holds the union of the two. If your security policy requires an application registration per workload, two registrations also work — each application has its own credential settings.
PDS does not authenticate to Microsoft at all. Everything it sends to SharePoint goes through CtrlSync, using CtrlSync’s credentials.
See Share one Entra registration for how to set that up.
What it does not do
Section titled “What it does not do”- It is not an application. There is nothing called CtrlTeams to install. Everything in this section is configuration spread across three applications that each install on their own.
- It does not decide the vault design. No template ships with it. The object types, classes, properties and workflows are built for each deployment, and the decisions above are the ones that are hard to take back.
- It does not manage Microsoft 365 itself. Governance, retention and licensing in Microsoft 365 stay where they are. What these applications do is keep M-Files holding the record of what happened.