Permission-aware Microsoft 365 intake: request to approved record

Everything on this page is invented for the demonstration: the organization, the people, the request, the records, and the audit entries. No client, no client system, and no production record was involved, and no measured business result is claimed. Read it as a description of how the parts fit together, not as evidence of work performed for a client.

Who this demonstration is for

Operations leaders, practice administrators, IT managers, and owners at organizations that already run email, documents, and sign-in on Microsoft 365, and keep the actual business in one internal application. The specifics differ from company to company, but the shape of the problem rarely does: work arrives as a message, and a person has to move it into another system by hand.

The operational problem

• Requests arrive by email and are handled in whatever order someone gets to them.
• The details needed to act on a request are spread across the message thread, one or two documents, and the application that holds the record of truth.
• Someone has to work out which policy or guidance currently applies, from a document library that is larger than anyone can hold in their head.
• The same details are typed a second time into the business application, which is where transcription errors and inconsistent phrasing come from.
• When the person who normally handles this is out, requests wait, and the backlog does not sort itself.
• Afterwards, nobody can reconstruct what was decided, on whose authority, or when.

The previous workflow

1. A request arrives in a shared mailbox.
2. Someone reads it, decides what it is, and guesses which internal guidance applies.
3. They open the document library, search for that guidance, and read enough of it to answer.
4. They summarize the request in their own words.
5. They open the business application and retype the summary and the relevant details into a new record or an existing one.
6. If something is missing, they email the requester and wait.
7. The message is filed or archived. The record keeps whatever they typed.

The failure points are structural, not personal. Triage depends on one person’s availability. Guidance is interpreted from memory. Anything retyped can be mistyped. Nothing in step 5 records who decided what, so a later question about a record is answered by scrolling a mailbox.

Success criteria

These were fixed before anything was built. Each one is a statement about behavior and control, not about a promised time saving.

1. Retrieval stays inside existing access. The assistant may only retrieve material the signed-in person is already allowed to open. It holds no standing access of its own.
2. Summaries are traceable. Every drafted summary names the approved sources it used, so a reader can check the draft against the same documents.
3. No silent writes. No record change executes without a named person approving that exact change. There is no auto-approve path and no timeout that approves on someone’s behalf.
4. Every execution is attributable. Each approved change produces a record of who submitted the request, what was proposed, who approved it, and when it ran.
5. Failure leaves the record untouched. A rejected, failed, or abandoned step leaves the business application exactly as it was.
6. The workflow can be stopped. The whole path can be switched off, leaving the manual process fully usable as before.

How the workflow runs

1. Intake. The request thread is the trigger. The requester’s message and any replies on that thread are the only inbox content in scope, so the assistant does not read a mailbox.
2. Retrieval with the requester’s permissions. The assistant signs in as the person handling the request and asks the document library for the approved guidance the request refers to. Anything that person cannot open is never retrieved, summarized, or sent to a model. This is what permission-aware retrieval means: the AI inherits the access a person already has rather than being granted a wider view.
3. Relevance check. Only the guidance set the organization has marked as approved is eligible. A document outside that set is not a source, even if it is in the library.
4. Draft. The assistant produces a short summary of the request, the specific guidance it relied on, and a proposed next step: the exact field values it intends to write into the business application’s record.
5. Permission decision. The workflow records which identity was used and whether each source was opened or refused, so the boundary is visible in the log rather than assumed.
6. Human approval. The draft and the proposed change go to a person who owns the request. They approve it as written, edit it, or discard it. Nothing is written before that decision.
7. Execution. On approval, one record update is sent to the business application through its documented interface — the endpoint the vendor or the internal team publishes for exactly this purpose.
8. Audit. The result of that single write is recorded, along with the decision that allowed it.

Systems involved

• Microsoft 365 mail — the request thread, read as the signed-in person.
• Microsoft 365 document library — the approved guidance documents used as sources.
• The internal business application — the record of truth, reached through one documented record-update endpoint and nothing else.
• An identity provider — the sign-in service that already issues accounts. In a Microsoft 365 environment that is Microsoft Entra ID; the pattern is the same wherever sign-in is centralized.
• The workflow service — the component that runs the assistant, holds the approval queue, and writes the audit event.

This list describes compatibility, not a partnership. Microsoft 365 is a product of Microsoft Corporation. EverythingAI is an independent consultancy, and this demonstration implies no sponsorship or endorsement by any vendor named here.

Data flow

• Enters. The request email thread, the guidance documents needed to answer it, and the requester’s stated details.
• Travels. The relevant excerpts and the drafted summary pass through the AI model provider that processes the text. That provider is chosen and disclosed as part of an engagement; it is never an unlisted background dependency.
• Retained. The proposed change, the approval decision, and the audit event are kept. The work is repeatable from those records without reopening the mailbox.
• Does not leave. Nothing outside the approved sources is read or sent. No credentials, no documents the person cannot already open, and no unrelated mailbox content.

Identity and permissions

Three identities are involved, and each one is deliberately narrow.

• The person. The requester or handler uses the account they already have. The workflow does not create shadow accounts for them and does not change what they can see.
• The assistant. It has no standing access of its own. It acts as the signed-in person for retrieval, so its reach is exactly that person’s reach. It cannot read a mailbox-wide scope, and it holds no administrative rights.
• The workflow service. To write the record, the service needs its own identity. That identity is granted permission to update one record type in one application and nothing else. It cannot read the document library and it cannot send mail.

Least privilege here is not an abstraction. It is the reason a request the handler is not cleared to see stops at step 2 with a refusal in the log instead of appearing in a summary.

Human approval

An approval is a decision about a specific change, not a general permission to proceed.

• The reviewer sees the summary, the sources it used, and the exact field values proposed.
• The reviewer can edit the values before approving, and the audit event records that the values were edited rather than approved as drafted.
• Discarding is a normal outcome. A discarded draft returns the request to the manual process.
• The approver is a person accountable for the record. The assistant never approves its own proposal, and no deadline converts silence into consent.

Logging, errors, and rollback

Each execution writes one audit event containing: the request thread identifier, the identity used for retrieval, the sources used and any refused, the proposed values, the approver, the decision, and the timestamp and outcome of the write.

Errors are handled at the boundary:

• If retrieval fails, the draft is not produced and the request stays manual.
• If the write fails, the application’s record is left unchanged, the error is reported to the approver, and the failure is logged.
• Because the workflow performs a single record update rather than a chain of edits, there is no partially applied state to reconstruct.
• Switching the workflow off returns the process to its previous manual form immediately.

Synthetic sample records

The four blocks below are the shape of the data a deployment produces. They are invented, they contain no real names, addresses, or identifiers, and they are not captures of a live system.

The request, as it arrives:

From: [email protected]
Subject: Onboarding request - 1450 Sample Avenue

We are taking over management of this property on
the 1st of next month. The previous manager is
leaving, so we need the standard intake record
opened and the move-in inspection scheduled.

Contact on site: Sam Rivera ([email protected])
Unit count: 24
Reference: previous manager's handover pack

The assistant’s draft, including the sources it relied on:

SUMMARY
  A 24-unit property at 1450 Sample Avenue changes
  management on the 1st of next month. Open the
  standard intake record and schedule the move-in
  inspection with the on-site contact.

SOURCES USED (approved guidance set)
  Intake-Handover-Standard.md       (opened)
  Inspection-Scheduling-Policy.md   (opened)
  Legacy-Handover-Notes-2019.md     (refused - not
                                     in approved set)

PROPOSED RECORD CHANGE  (type: Property Intake)
  property_address     "1450 Sample Avenue"
  unit_count           24
  management_start     "2026-10-01"
  site_contact         "Sam Rivera"
  inspection_required  true
  intake_source        "email - handover"

What the approver sees and what is recorded when they approve:

APPROVAL DECISION
  proposed_by     workflow service (assistant)
  approved_by     [email protected]
  decision        approved as drafted
  approved_at     2026-03-02T14:11:20Z
  execution       record updated (1 field changed)
  audit_event_id  audit-7f2c41

Failures read the same way, with the record left alone:

APPROVAL DECISION
  approved_by     [email protected]
  decision        approved after edit
                  (unit_count 24 -> 26, contact updated)
  execution       update failed: endpoint returned
                  409 (record locked)
  outcome         record unchanged; handler notified;
                  manual process continues

What this demonstration proves

• A request can be summarized from approved sources using only the permissions the signed-in person already has, with refused sources visible in the record.
• An AI-proposed record change can be held behind a specific human decision instead of executing on its own.
• The decision, the authorizer, and the result of the write can be recorded in one audit trail.
• A failed write can leave the business record untouched rather than half-updated.
• The whole path can be described end to end, which is what makes it reviewable by the people who own the process.

What this demonstration does not prove

• No business result. There is no measured saving, error rate, throughput figure, or satisfaction score here. A synthetic scenario cannot produce one, and this page claims none.
• No security certification. Nothing here states or implies compliance with any framework, regulation, or contractual standard. Those questions depend on the organization’s own requirements, its data, and its review process.
• One environment is not every environment. Document libraries, applications, and permission models differ. Where an application has no supported way to update a record, the workflow has to change or the idea has to be set aside.
• The AI provider still processes the text. Retrieval can be permission-aware while the excerpts still leave the organization’s boundary for processing. That trade-off is examined and disclosed per engagement, not hidden by this demonstration.
• Untrusted content remains a real risk. A request or document can contain text designed to mislead an assistant. This workflow limits the blast radius to what a person is already allowed to see and to changes a person must approve, but it does not remove the risk.
• Retention, access review, and ownership stay with the client. Keeping permissions accurate as staff change, deciding how long records and logs are kept, and naming who is accountable for the workflow are ongoing responsibilities that no demonstration performs.
• The manual process is still the fallback. A demonstration does not replace a documented procedure, and it does not remove the need for one.

Publication safety

Confirmed before publishing this page:

• No client name, personnel, internal address, tenant identifier, credential, ticket content, or document text appears anywhere on this page.
• Every record, name, address, and log entry shown above is invented for the demonstration and is labeled as synthetic wherever it appears.
• The example addresses use example.com, and the identifiers shown are made up rather than redacted.
• Vendor names are used factually to describe compatibility, and no vendor has endorsed, sponsored, or reviewed this work.
• The demonstration was built and tested in a non-production environment against synthetic records.