Building the Standards on Microsoft 365

1. What this is, and what it is not

This is an implementation option. The compliance calendar, rejected pack, database reactivation, debtor chasing, invoice check and cited answer standards are the specification. Nothing here overrides them. If this page and a standard disagree, the standard wins and this page has a bug.

It is written for the business that already has Microsoft 365, has somebody who can build a flow, and has been told that doing any of this properly means a platform purchase. It usually does not. What it means is deciding which rules are allowed to live in a column.

Every standard has its own build plan, mapping that standard’s checks to the list, flow or measure that enforces them. This page is the shared shape they all assume.

• the compliance calendar on Microsoft 365
• the rejected pack on Microsoft 365
• checking subcontractor invoices on Microsoft 365
• debtor chasing on Microsoft 365
• database reactivation on Microsoft 365
• rent arrears on Microsoft 365
• the cited answer on Microsoft 365
• multi-site conformance on Microsoft 365
• inbox triage on Microsoft 365

Start with the standard, not the plan. The plan assumes you have read it and it will not repeat the argument.

It is not an argument that Microsoft is the right stack. If your work already lives in a job management system, the answer is to sit beside it rather than migrate. That is path B below, and it is the more common of the two.

If the business runs on Google instead, the companion page is building the standards on Google Workspace: same objects, same gates, same six measures, on AppSheet, Apps Script and Looker Studio. Read the one that matches the licence you already hold rather than both.

Both answer where the work lives. If you have already built an agent and the question is what keeps it running, read building agents that run the work.

2. Two ways to land it

Same gates and same reports on both. The thing that must not differ between them, or between two branches on the same path, is the shape of the records. Extra fields are fine. Different keys are not, and a fortnight is long enough for two branches to invent incompatible ones.

3. The objects, as lists

One site, one permission model, one set of keys. The names below are generic on purpose: a fire business, a property manager and a subcontractor each read them differently and the shape does not change.

Site: Operations

Rules          rule_id, instrument, clause, jurisdiction,
               frequency, effective_from, effective_to
Subjects       subject_id, client, location, class, rule_id,
               last_pass_at, status (active | blocked | retired)
Work           work_id, subject_id, window, assignee,
               result, queue
Evidence       work_id, file, captured_by, captured_at, kind
Exceptions     work_id or subject_id, code (closed list),
               owner, review_by
Contacts       subject_id, channel, outcome, contacted_at
People         person, competency, expires_on, assessed_by
Segments       segment, entra_group, owner

Libraries      Evidence files, Instruments, Output documents

Keys are shared. A branch may add columns. A branch may not
rename or fork subject_id, rule_id or work_id.

Evidence is a list with a library behind it rather than an attachment column, because an attachment cannot be queried, cannot be counted, and cannot tell you what is missing. Counting what is missing is the entire job.

4. The gates, which must be flows

This is the part that decides whether you implemented a standard or drew one. A gate is a rule a person cannot type past. In this stack that means a flow, a list validation, or a measure. It does not mean a column, a view, a colour, or a line in a training document.

1. Derive the date. On create or update of a Subject, compute the next obligation from the rule and the anchor. A person may override only into a separate override field carrying their name and a reason, and the override shows in the reporting.
2. Hold the clock when blocked. A subject that cannot be reached does not silently roll forward. The status changes, the obligation stays live, and a review date is set.
3. Refuse the close. Work cannot reach a completed state until the evidence rows the class requires exist. Missing evidence is its own queue, and that queue is not the same thing as a pass.
4. Write the rank. A scheduled flow scores and stores the rank on the row. Nobody sorts a sheet, and the reason a row is top is a value somebody can read.
5. Suppress before contacting. The contact step checks the suppression conditions first. This is a gate rather than a filter in a view, because a view is per person and a gate is not.
6. Check competency before assigning. Work of a class cannot be assigned to somebody whose competency is missing or expired. The check reads the People list at assignment time.
7. Escalate on a clock, not on a feeling. Anything in a queue past its threshold posts to a named channel with the record attached and an acknowledgement recorded.

Teams is where the gates surface, not where they live. An adaptive card is a good way to ask a person for a decision and a bad place to keep the only record of it. Whatever the person chooses is written back to the list.

5. Power BI holds the argument

The reporting layer is not decoration here and it is not a dashboard exercise. Every standard makes a claim about how the work runs. Power BI is where that claim is either true or visibly not, in front of people who can do something about it.

Build one model over the lists rather than a report per team. The relationships follow the keys: Rules to Subjects, Subjects to Work, Work to Evidence and Exceptions, Segments to Subjects. Six measures do most of the work, and they belong in the model rather than buried in a report filter where only their author can find them.

• ✓Derived rate. The share of records whose date was computed rather than typed. It should approach one, and the gap is your list of exceptions.
• ✓Unbound records. Work marked done with no evidence attached. The target is zero and the useful chart is how long each one has been open.
• ✓Override rate. Every manual override with who did it and why. A rising line here is the standard being worked around, not broken.
• ✓Coverage. The share of the book with a live future obligation. This is the number that says whether the system describes the business or only part of it.
• ✓Actioned. Ranked items that got a job or a logged contact inside the window. Ranking nobody works is a report, not a process.
• ✓Gate latency. Time from something entering a queue to a person acting on it. The gates are the design; this says whether they are staffed.

Row level security maps to the Segments list through Entra group membership, never a name typed into a report. A branch sees its own book, the centre sees all of it, and the same measures produce both so the two are never arguing about different numbers.

Publish into the Teams channels the flows already post to. An email subscription is a backup. If the only place the numbers appear is a monthly attachment, the reporting layer is not part of the operating rhythm and it will stop being maintained.

6. Seven things not to hand-roll here

Each of these is easy in a spreadsheet, works for about a month, and fails in a way that looks like a people problem rather than a design one.

7. Provider: what to stub, and what not to hand-roll

Almost all of this is yours to build, which is the point of the page. Two things are worth naming, and one of them is a warning rather than a recommendation.

stub in development
  - lists with a handful of rows and a manual trigger
  - a flow that logs instead of sending
  - one report page, no row level security

production
  - record, gates, reporting: your own tenant. Ordinary build.
  - field capture: a Power App, or the job system's own app
    where path B applies. Do not build two capture surfaces.
  - voice on the phone number: a product, where the enquiry
    standard calls for one. It writes to the same lists.
  - the person on each gate: a person. No product.

do not hand-roll
  - the derive step and the refuse-to-close step. Everything
    else here degrades gracefully. Those two are the standard.

A warning specific to this stack: a licence is not an implementation. Owning Power Automate and Power BI is what makes this cheap, and it is also what makes a half-built version look finished. The conformance checklist below is the difference.

8. Conformance checklist

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. Dates are written by a flow, not typed into a column. A manual edit is either blocked or recorded as a named override
• ✓2. Completion is a flow that can refuse. Work with missing evidence cannot reach a completed state
• ✓3. Rank is stored or measured, never a sort order. Anyone can read why a row is at the top
• ✓4. Suppression is checked at the contact step. Not a filter on somebody's personal view
• ✓5. One set of keys across every branch and both paths. Extra columns are fine. Renamed or forked keys are not
• ✓6. Power BI reads the lists, never a working spreadsheet. No refresh depends on somebody reformatting a file
• ✓7. Row level security comes from Entra group membership. No names typed into a report
• ✓8. Every queue has a named owner and an escalation clock. A queue nobody owns is a list of things not happening
• ✓9. No second register outside the site. If a branch starts in Excel, the file lives in the site and a flow upserts it
• ✓10. Someone other than the builder can explain what it does, and it runs on an account the business owns. The tenant, the flows and the model survive the person who set them up