A scroll-through of the platform: what we replace, where we sit in your stack, what the team actually sees, and why DMS still feels like one product after more than 25 years of accumulated diocesan know-how.
Most dioceses we meet are running their operations across a tangle of independent tools: a safeguarding spreadsheet, a finance package, an HR system that nobody likes, a parish CMS and three Outlook inboxes that act as the source of truth for vacancies.
The diocesan secretary holds it all together by hand. When that person retires, the institutional memory retires with them.
We are not the system of record for clergy and parish data. The National CMS is, and will remain so. DMS sits as the operations layer above it, pulling person and place data down, pushing updates back, and adding the 25+ operational areas the National CMS will never cover.
This matters: it means you don't double-key, your safeguarding officer doesn't disagree with your archdeacon about who works where, and you keep the integrity guarantees the National CMS provides.
The temptation when you build for the Church of England is to keep adding modules. A safeguarding module, a faculty module, a net-zero module, each with its own log-in, its own data model and its own sales call.
We took the opposite path. One platform, 587 Eloquent models, 25+ areas, all sharing the same person, place, role and document spines. Adding a new area is a folder of code, not a separate system. The list below is a representative sample.
Every platform claims its areas are connected. The question is what happens when two of them disagree — when a licence says one thing and the post register says another, when a church is on the Heritage at Risk register but nobody has logged a conversation in a year.
So the platform ships a page called How it fits together: the whole system on one screen, module by module, with live checks that show exactly where two areas contradict each other. Not a diagram of how it should work — a list of the places it currently doesn’t, with links to fix them.
Beside it sits the clergy lifecycle: everybody from discernment to retirement, placed by the job category of the post they actually hold. Nobody maintains that list; it is derived. When someone takes up a new post, they move stage overnight — and their safeguarding requirement changes with them.
Where the national systems stop → · The place spine it all hangs off →
Different people in a diocese need radically different views, and radically different things hidden from them. DMS is built around the role rather than the individual user. The DSA sees safeguarding cycles, the DAC officer sees faculty queues, the diocesan secretary sees the lot.
A safeguarding case is invisible to a treasurer. A finance ledger is invisible to a churchwarden. The platform enforces it; the user never has to remember.
The "single pane of glass". Everything from vacancy pipelines to risk register, in one place, with the right escalations on the homepage.
Dashboards & reporting →One Person 360 with full history, DBS state machine, automatic 60-month escalation, encrypted document store.
Safeguarding & DBS →Faculty queue, pre-triaged petitions, statutory consultee tracking, audit trail by petition number.
Church care, DAC & faculties →Pastoral hierarchy view: every parish, every vacancy, every quinquennial, on a map and in a list.
Pastoral planning →Parish share, grants, PSO movements. Statement export to Sage / Xero. Reconciliation in hours, not weeks.
Finance & Parish Share →Self-service portal: parish returns, electoral roll, faculty applications, safeguarding declarations.
The Parish Portal →The reason DMS doesn't feel like a Frankenstein after more than 25 years is not architecture. It's that every diocese runs the same code. We don't fork. We don't customise. New requirements either become configuration, or they become features that benefit everyone.
The team that built area ① is the team that builds area ㉕. The release cadence is monthly and the migration path is automatic. You upgrade by waking up on a Tuesday.