Microsoft 365 & Power Platform
Development Standards & Architecture Guide

This is a living document. It is deliberately incomplete: it contains decided standards, drafts awaiting confirmation, and open questions you still need to answer. The empty space is the point — fill it in as decisions get made, and record the date and reasoning when you do.

The one rule this document enforces

How a decision gets recorded here

Propose it (in writing, with the why) → discuss it with whoever it affects → decide it → record it using the template in Appendix A → log the edit in Appendix B. Decisions get an ID (DA-001, NC-002, …) so flows, app comments, and wiki pages can cite them.

Revisiting decisions

Every decision record has a Revisit when field. Decisions are made against constraints — licensing terms, tenant policy, platform features — and constraints change. Naming the trigger for re-evaluation up front prevents both blind loyalty to stale rules and constant relitigation of settled ones.

Naming is the cheapest form of documentation and the only one guaranteed to be seen at the moment of use. The goal of a convention is not tidiness — it is that any team member can open an unfamiliar app or flow and predict what a thing is, who owns it, and what it touches, from its name alone.

DraftProposed defaults — confirm or revise

BaselineMicrosoft’s positions — from the canvas app standards white paper

Microsoft’s Power Apps canvas app coding standards and guidelines white paper (Appendix D) is the closest thing to an official baseline, and the table above already agrees with most of it: camelCase controls with short type prefixes, gbl/loc/col prefixes, PascalCase data sources. Its additions worth deciding on:

• Why the variable prefixes exist at all: Power Fx allows a context variable and a global variable to share a name, and formulas silently resolve to the context one unless disambiguated. The gbl/loc prefixes aren’t taste — they make that collision impossible. Worth writing into the standard so the rule survives its author.
• Reused controls carry a screen suffix: control names must be unique app-wide, so a control repeated across screens gets a short screen tag (their example: a nav gallery suffixed for the home screen). Decide whether to adopt this or forbid cross-screen duplication outright in favor of components (§10) — components didn’t exist when the paper was written.
• Custom connector naming happens before import: the OpenAPI title attribute becomes the data source name with spaces stripped, so set a clean PascalCase title first — it can’t be fixed afterward. Feeds §08’s custom connector policy.
• Type prefixes for data-typed variables (e.g., str, b) are explicitly left to team preference by the paper. Decide once below.

OpenQuestions you need to answer

• What is the official app-code registry (e.g., PCARD, TRNRM) and who assigns codes?
• Singular or plural list names — which one, permanently?
• Do environment names carry a suffix convention (-DEV / -TEST / -PROD), and do solution and flow names repeat it or rely on the environment context?
• What is the naming pattern for service accounts and app registrations? (Feeds §03.)
• Are flow action names inside a flow renamed to describe intent, and is that enforced in peer review?Why it matters: “Apply to each 4” is where debugging goes to die.
• What naming marks something as deprecated but not yet deleted (e.g., zzOLD_ prefix)?

Every rule in this document eventually resolves to an Entra ID object. Who can open an app, whose rows a flow returns, who may approve, who gets the notification, who can run the script — each is a lookup against a user, a group, or a service identity. Get identity wrong and the standards above it are decoration.

DraftProposed practices — each with its why

OpenQuestions you need to answer

• What is the group naming standard, who may create groups, and is self-service creation on or off today?Why it matters: this one setting determines whether §11’s site architecture is a plan or a suggestion.
• For app audiences — dynamic or assigned? If dynamic, which attributes are trustworthy enough to drive access, and who owns their accuracy?
• Which roles are PIM-eligible versus standing, what is the maximum activation window, and who approves activation?
• Which Conditional Access policies touch Power Platform, SharePoint, and Graph — and does anyone test releases against them before users do?
• What is the guest access posture per workload, and what expires an unused guest?
• How many break-glass accounts exist, where are the credentials, and when were they last tested?
• What does the government-cloud environment change here — which identity features are unavailable or behave differently, and where is that recorded so it isn’t rediscovered quarterly?
• What is the access review cadence for groups, and does completing it produce evidence an auditor would accept?

DA-001 makes identity an architectural feature: flows deliberately run as something other than the end user. That “something” must be chosen, secured, documented, and survivable when people leave. Two distinct instruments exist and should not be conflated: service accounts (licensed user identities that own connections and flows) and service principals / app registrations (non-user identities for API-level access, e.g., Microsoft Graph or SharePoint app-only calls).

OpenQuestions you need to answer

• One service account per app, per department, or per environment tier? What is the blast radius you are willing to accept if one credential is compromised?
• Where are service account credentials stored, who can retrieve them, and what is the break-glass procedure?
• What is the secret/credential rotation cadence, and who owns the calendar reminder that actually makes it happen?
• When is a true service principal (app registration) required instead of a service account — e.g., Graph API calls, app-only SharePoint access — and who approves new app registrations?
• Certificates or client secrets for app registrations, and what expiry ceiling is allowed?Why it matters: the default temptation is a 24-month secret created in a hurry; the incident happens in month 25.
• What Entra ID roles/permissions is a service account allowed to hold, and what is categorically forbidden (e.g., no standing admin roles — use PIM)?
• How are service accounts and app registrations inventoried and reviewed — and does that review satisfy your compliance frameworks (e.g., CJIS/HIPAA-adjacent audit expectations)?

DA-001 claims row-level security. That claim is only true when three layers agree: the SharePoint lists are locked down, the flows run under the service identity for everyone, and the app is shared to the right people. Get any one wrong and the model silently degrades to “everyone can see everything, just less conveniently.”

DraftFurther proposed practices

OpenQuestions you need to answer

• Which compliance frameworks formally apply to which data classes here, and what specific controls do they demand from Power Platform solutions?
• What audit evidence must solutions produce (who did what, when), and is flow-written stamping (§11) sufficient or is centralized logging required?
• Who performs periodic access reviews of app shares, group memberships, run-only lists, and service identities — and how is completion evidenced?
• What is the incident procedure if a service account credential is exposed — rotation steps, connection re-auth, and communication?
• What is the exception process when someone requests direct list access “just for reporting”?Why it matters: this is the single most common way the SEC-001 model gets quietly broken.
• Are guest/external identities ever in scope for these apps, and what changes if so?

Solutions built here hold public-sector data, some of it regulated. That makes retention, classification, auditability, and discoverability design inputs — not paperwork applied afterward. This section is where those obligations get named, so §04 can select controls and §07 can size its data model against them.

DraftProposed practices — each with its why

OpenQuestions you need to answer

• Which frameworks formally apply to which data classes — CJIS, HIPAA, state records law, PCI-adjacent for payment workflows — and who is the authority that answers this, not guesses at it?Why it matters: the P-Card workflow touches purchasing data; the answer shapes §04’s control set for it.
• What is the records retention schedule for app-held data, and who is the records custodian for a SharePoint list?
• What is the current state of Purview DLP, and does it inspect anything in the app-backing sites?
• Are sensitivity labels in use, and do they enforce anything or merely mark?
• What is the audit log retention period today, and what is the longest retention obligation any solution carries?
• Who signs off that a solution is compliant before it ships, and what artifact records that sign-off?
• What is the breach/incident procedure specific to app data, and how does it differ by classification?

“Never go premium” and “just buy premium” are both reflexes. The standard here is a framework: premium is a purchase of specific capabilities (Dataverse’s relational integrity and security roles, premium connectors, higher limits) at a specific multiplication factor (per user? per app? per flow?). The decision is legitimate only when the capability gap and the multiplication factor are both written down.

Decision framework — work these in order

Precedent worth recording: the P-Card approvals app was re-platformed from Dataverse to SharePoint lists after a licensing review — a live example of question 3 changing the answer. Write up that case below while the details are fresh; institutional memory of why is exactly what this document exists to hold.

OpenQuestions you need to answer

• What licenses does the organization actually hold today (seeded plans, per-app, per-user, process/flow-level), and where is that inventory kept current?
• What is the approval threshold — can a maker decide premium for a 5-user tool, or does every premium decision route through the same gate?
• At what point does an app’s scale or data sensitivity force the Dataverse conversation regardless of cost (security roles, auditing, relational integrity)?
• How do you monitor for accidental premium — a maker dropping a premium connector into an app and flagging every user?Why it matters: the platform will happily let this happen silently; the license true-up will not be silent.
• What is the standing answer for AI Builder / Copilot Studio credits, which carry their own consumption model?

Data access is the highest-leverage architectural decision in a Power Platform solution. It determines licensing exposure, the security model, performance characteristics, and how much of your logic lives server-side versus in the app. It is decided first because most other sections inherit constraints from it.

External corroboration: Microsoft’s own canvas app standards white paper (Appendix D) recommends this same layering for SQL back ends — routing data operations through a flow that calls stored procedures — for performance, for decoupling the app from schema changes, and for tighter security via a restricted execute-only identity. DA-001 applies that reasoning to SharePoint, with licensing containment added on top.

OpenQuestions you need to answer

• What is the pagination contract for read flows — page size, page token or skip count, and who enforces the cap?Why it matters: without a contract, someone will eventually return 5,000 rows in one response and blame the platform for the timeout.
• What is the app-side caching policy — which datasets get loaded into collections once per session, and which are re-fetched on every screen visit?
• What is the timeout and retry behavior when a flow call fails mid-session? Silent retry, user-facing notification, or both?
• How do you handle concurrent edits — last-write-wins, a version/ETag check in the update flow, or record locking via a status column?Why it matters: approval apps invite two approvers acting on the same record within seconds of each other.
• How are attachments and images handled, given the flow-mediated model? (Attachments often tempt teams back to direct connectors — decide the pattern before that happens.)
• What payload size is “too big” for a single Respond action, and what is the fallback pattern when you hit it?
• Do read flows and write flows live in the same flow per entity, or separate flows per operation (Get / Create / Update / Delete)?

A connector is three things at once: a capability, a licensing trigger, and a hole in your data boundary. Strategy means deciding all three deliberately — which connectors are sanctioned, how new ones get approved, and how DLP policy encodes those answers so the platform enforces them instead of relying on memory.

OpenQuestions you need to answer

• What is the sanctioned connector list for app-layer use vs. flow-layer use? (Under DA-001 these are different lists — the app layer should be close to “SharePoint via flows, Office 365 Users, and little else.”)
• What do your DLP policies actually say today — which connectors sit in Business vs. Non-Business vs. Blocked, and does that match this document or contradict it?Why it matters: an undocumented DLP policy is a standard someone else wrote for you.
• Who approves adding a connector to the sanctioned list, and what evidence is required (data touched, auth model, license class, vendor posture)?
• What is the policy on the HTTP connector and custom connectors — banned, approval-gated, or free? Who reviews the endpoints they call?
• Are consumer-grade connectors (personal cloud storage, social) blocked tenant-wide, and is that documented here with the reasoning?
• How do government-cloud constraints affect connector availability, and where do you record “not available in our cloud” findings so they aren’t rediscovered quarterly?
• What happens when a needed connector is premium — what is the escalation path into the §06 decision framework?

Because DA-001 routes all data operations through flows, flow quality is solution quality. These patterns treat each app-facing flow as a small API endpoint: typed inputs, predictable outputs, explicit error handling, and no silent failure.

DraftProposed patterns — each with its why

OpenQuestions you need to answer

• What is the synchronous budget — how long may an app-facing flow run before it must be redesigned as async (queue + notify) instead of making the user wait?
• Where do flow errors go besides the envelope — a logging list, email to owners, Teams channel? Who is on the hook to look?
• Are solutions mandatory for all flows (enabling connection references and environment variables), including quick utility flows?
• What is the standard for environment variables — which values must never be hard-coded (site URLs, list names, recipient groups)?Why it matters: hard-coded URLs are the #1 reason a “tested” flow fails on the first day in production.
• Do you require an idempotency strategy for create operations (dedupe key, existence check), and what is the default?
• What is your policy on nested loops and per-item lookups vs. Filter Query — when is a design sent back in review for performance?

Canvas apps have no enforced architecture — every app is a folder of screens and formulas arranged however its author was feeling. Structure standards exist so the team’s apps converge on one internal shape: where state lives, how screens talk to each other, how errors surface, and what the user sees while data loads.

DraftProposed structure — each with its why

BaselineMicrosoft’s white paper positions — proposed stance on each

The same Microsoft white paper (Appendix D) covers app construction — but its feature coverage stops at late 2018, before named formulas, modern controls, or components matured. That makes it a perfect exercise for this document’s philosophy: a baseline is an input, not an authority. Proposed stances below; confirm each and record divergences.

DraftDebugging & diagnostics

The white paper devotes a full section to debug affordances built into the app itself: a semi-transparent canvas panel showing live variable state, toggle controls that let a maker force an error condition and watch the UI react, and an identity check that keeps all of it invisible to end users. That instinct matters more under DA-001, not less — when data arrives as a JSON payload from a flow rather than a bound data source, “what did the app actually receive?” becomes a question you ask constantly, and a debug panel answers it without a republish.

Two of its three patterns still hold. The debug panel (a maker-only overlay listing globals, collection counts, and the last flow envelope) is worth building into the house screen template. The toggle-control error pattern is superseded: it was a workaround from an era before formula-level error handling, and IfError / IsError now express the same thing directly, closer to the failure. The third — how you decide who sees any of it — needs a decision, because the paper’s answer conflicts with a standard already recorded in this document.

OpenQuestions you need to answer

• What is the screen inventory convention — is there a required set (Home, Detail, Admin, About/Version) and a maximum before an app should split?
• When does the component library become mandatory, and who curates it?
• What is the versioning display standard — do apps show a version and environment label to users, and where?Why it matters: “which version are you on?” is the first support question; the answer should be on screen.
• What is the performance budget (startup time, screen-load time) and how is it measured before release?
• What is the offline stance — explicitly unsupported, or designed for where field work demands it?
• Which formula patterns are banned or discouraged in review (e.g., heavy logic in visible/OnChange chains, N+1 lookups inside galleries)?
• Which security group gates debug affordances — one per app family, or one across all Power Platform solutions?Why it matters: one group is easier to run and leaks diagnostics across unrelated apps; per-app groups are precise and multiply the review burden.
• Is the Power Apps for Makers connector premium in our tenant, and does that alone disqualify it from the app layer? (Feeds §08’s sanctioned list and §06’s accidental-premium monitoring.)
• May makers enable preview or experimental app settings freely in dev, and what evidence is required to carry one into production?
• Does the house screen template ship the debug panel by default, or is it added per app on request?

DA-001 makes SharePoint the system of record, accessed through flows. That shifts where SharePoint’s sharp edges cut: delegation warnings in the app matter less, but list design, throughput limits, and site permissions matter more — because the flow layer inherits them all.

DraftProposed practices — each with its why

OpenQuestions you need to answer

• Who provisions app sites — makers, or an admin gate — and from what template?
• What is the archival strategy when a list approaches size thresholds (yearly archive lists, a rollover flow, or deletion policy)?
• Where does the canonical schema documentation live for each list, and is it generated or hand-maintained?
• What is the standard for calculated columns and Power Automate-maintained denormalized fields — allowed, and who owns keeping them true?
• How are list-level backups/restores handled beyond versioning — is Recycle Bin + versioning officially “enough,” and for which data classes is it not?Why it matters: the honest answer differs for a room-booking list vs. anything touching regulated data.

Teams matters here for two reasons: it is the surface where flow-driven approvals reach a human, and it silently provisions the SharePoint sites §11 tries to govern. Both need decisions.

DraftProposed practices — each with its why

OpenQuestions you need to answer

• Are approvals delivered by adaptive card, email, or the app itself — and what is the fallback when the primary channel fails?
• Are private channels permitted? If so, how do their site collections get inventoried and secured under §11 and §04?
• Who can create teams today, and does that match §02’s answer on self-service group creation?
• What is the team naming and expiration policy, and who handles the expiry notifications when the owner has left?
• Do any solutions ship as Teams tabs, and is that a supported pattern here or an exception?
• Are shared channels (external participants) in scope, and what does that change for §04 and §05?

Under §07, flows run as a service identity — which means that by default, every notification an app sends appears to come from a service account nobody recognizes, or worse, from whoever happened to own the connection. Mail is the most visible artifact most solutions produce. It deserves a deliberate answer.

DraftProposed practices — each with its why

OpenQuestions you need to answer

• Which shared mailbox belongs to which solution, and who provisions and monitors it?
• Send As or Send On Behalf — and is the permission grant documented alongside the service account in §03?
• May app mail reach external recipients, and what changes for §05 when it does?
• Do any mail flow rules or connectors silently modify or quarantine app-generated mail?Why it matters: a transport rule written for a different reason is a classic cause of “the flow ran but nobody got the email.”
• What is the largest audience any single flow mails, and does that sit inside the connector’s send limits?
• Are notification templates standardized (branding, tone, footer, unsubscribe/where-to-go-for-help), and where do they live?

Scripts are where governance quietly stops. Apps get reviewed, flows live in solutions, and meanwhile a PowerShell file on somebody’s desktop holds an application-permission token that can read every mailbox in the tenant, runs on a scheduled task nobody documented, and is understood by exactly one person. This section exists to make scripts first-class: sourced, scoped, reviewed, and survivable.

DraftProposed practices — each with its why

OpenQuestions you need to answer

• Where do scripts live today — and honestly, how many production-affecting scripts are running from a personal machine on a scheduled task right now?Why it matters: this is the single most common ungoverned-automation finding, and the inventory is usually shorter than feared and scarier than expected. Find it before an offboarding does.
• Where should they run — Azure Automation, Functions, a managed jump host, a pipeline? What is the cost and the approval path?
• Who approves an application permission, and what evidence is required?
• One app registration per script, per function, or per team? What blast radius is acceptable?
• Certificates or secrets, and what is the maximum expiry allowed for each?
• Who reviews scripts before they run against production, and against what checklist?
• What is the inventory of existing app registrations and their granted scopes — and when was it last reconciled against what’s actually in use?
• Are any scripts still on retired modules, and what is the migration plan and deadline?

Deployment is where good builds go to embarrass their authors. The standard here is boring on purpose: separate environments, solution-based packaging, externalized configuration, and a checklist that verifies the things the platform will not verify for you — especially the SEC-001 settings that silently define your security model.

DraftProposed baseline

OpenQuestions you need to answer

• Manual export/import or pipeline-based ALM — and if pipelines, which tooling is actually available and approved in your cloud/tenant?
• Where do test scripts live, and what is the minimum test coverage for an app-facing flow (happy path + which failure paths)?
• Who owns UAT sign-off per solution, and is sign-off recorded somewhere durable?
• What is the release cadence and change-window policy — can production deploys happen any time, or scheduled windows only?
• How is test data handled — synthetic only, scrubbed copies, or (decide explicitly) never production data in lower environments?Why it matters: regulated data in a dev environment is a compliance incident nobody planned.
• What is monitored post-deploy (flow failure rates, app errors) and for how long before a release is “settled”?

Standards fail socially before they fail technically. This section covers how work is shared, reviewed, documented, and handed off — the practices that make the other ten sections survive personnel changes, deadline pressure, and the fact that canvas apps still effectively allow one editor at a time.

DraftProposed practices

OpenQuestions you need to answer

• Who are the named reviewers, and what turnaround is promised so review never becomes the excuse to skip review?
• Where does the claim board / work log live, and is it actually lightweight enough that people use it?
• What is the training and certification plan per team member, and how is time for it protected?
• What is the intake process for new app requests — how do ideas get sized, prioritized, and assigned against this standard from day one?
• How are citizen developers outside the core team handled — free rein in a sandboxed environment, mentorship track, or gated intake?Why it matters: this decision determines whether governance feels like enablement or like a wall.
• What is the cadence for reviewing this document itself, and who runs that meeting?

Copy the block below (in the HTML source it’s marked with TEMPLATE — COPY FROM HERE) into the relevant section. Set the class to dr decided, dr draft, or dr openq, and update the stamp text to match. Every field is mandatory except Mitigations — if you can’t write the Why, the decision isn’t ready.