Connecting Carers: Technical Discovery
Making a complex digital estate understandable before anyone recommends changing it.
Illustrative overview of the method. The full audit records are confidential.
Scottish Tech Army · Voluntary · Dynamics 365 · Dataverse · Power Automate · SharePoint · WordPress · Application source review
The Problem
Connecting Carers is a charity supporting unpaid carers. Its staff depend on a CRM for daily casework, alongside a public website and a mobile app. The systems had been built and extended by different suppliers over several years, and there was no single, trusted description of how they fitted together.
That is a common position for a charity, and a risky one. Decisions about what to fix, replace or commission were being made from memory and assumption. Before recommending any change, the organisation needed to know what it actually had.
I took this on as a volunteer through the Scottish Tech Army, following earlier discovery reports for the same charity.
The Method
I treated it as an evidence exercise. Four rules shaped the work.
1. Read-only, by design
Every inspection was read-only. I looked at configuration, structure and record counts and changed nothing. The boundaries were written down before I started, so the client knew exactly what had and had not been touched.
2. Every statement has a source
Each claim in the system map points to a numbered evidence file and the time it was observed. Counts taken at different times of day are labelled as such, so nobody adds together figures that were never comparable.
3. Observed is not the same as assumed
The report separates what I saw, what I calculated from what I saw, and what people believed to be true. An integration that is referenced in source code is recorded as referenced, not as working, unless I could verify it.
4. Say what was not tested
Where I reviewed application source without running the app, the report says so. Where a measure cannot answer a question (a blank link field does not prove a record is missing) the report says that too.
What I Examined
- The CRM. A Dynamics 365 environment on Dataverse, used through a model-driven Power App: tables, relationships, forms, views, business rules and how completely the links between records are filled in.
- Automation. Power Automate processes that update records, and their recorded run history.
- Documents and email. How SharePoint document storage and email synchronisation attach to CRM records.
- The website. The WordPress site, and whether its activity reaches the CRM.
- The mobile app. The application source, and the services it refers to.
Illustrative diagram of the approach. It is a public overview, not a screenshot of client systems.
What I Delivered
- A verified system map of the whole estate, revised through several versions as evidence came in, and finalised on 30 October 2026.
- A verification guide and inspection log, so that someone else can repeat any check and get the same answer.
- An evidence pack of numbered files that the map refers to.
- A management briefing in plain English, with diagrams, for trustees and managers who need to make decisions and do not need the table names.
The result is a shared, checkable picture. The charity can now ask a supplier a precise question, and can tell whether the answer is right.
"His ability to delve into and understand undocumented technical environments has been invaluable."
What This Demonstrates
- Getting to grips quickly with an undocumented Dynamics 365 and Power Platform estate
- Disciplined evidence handling: sources, timestamps and clear limits
- Writing for two audiences from one body of evidence, technical and managerial
- Working safely in a system that holds sensitive personal data
Related work: Digital consultancy projects · Power Platform · Copilot Studio governance