How Do You Build a Marketing Approval Trail With Microsoft Lists and Power Automate?

Build a Microsoft Lists and Power Automate approval trail with exact fields, append-only evidence, role boundaries, exception tests and a worked item.

Short answer: answer: Store each release request in Microsoft Lists, run Start and wait for an approval, then append a separate decision-evidence item containing actor, outcome, timestamp, comments and the exact asset version. Update the request’s current status only after that evidence write succeeds. Email is a notification channel, not the approval record, and SharePoint version history alone is not immutable evidence.

Most examples stop when an approval card returns “Approved.” That can launch work, but a future reviewer still needs to know what version was approved, under which rule, by whom and whether the evidence record survived later edits.

Calling version history immutable creates false confidence. Microsoft documents version permissions, including the ability for authorized users to delete versions. Strong retention requirements need records-management controls beyond a normal list.

The Approval Evidence Flow

CDM’s Approval Evidence Flow has Request, Decision, Release and Reconciliation stages. Our position is: the flow must write a distinct decision event before it changes the operational status to Approved. A mutable status cell is a current view, not an audit trail.

Stage 1: create the request record

Build a Marketing Releases list with these columns:

Create a second Approval Evidence list: Evidence ID, Release ID, submitted version/hash, approval type, assigned approvers, actual responder, outcome, response time, comments, approval service ID, flow run ID and prior Evidence ID. Restrict deletion and editing as far as the governance model permits.

Stage 2: start one defined approval

Trigger when Current status becomes Ready to submit, then validate required fields and rights date. Set Pending, generate a correlation ID and call the current Start and wait for an approval action. Microsoft documents approval types including first responder, everyone must approve, custom responses and sequential patterns. Choose one in policy rather than letting requesters decide ad hoc.

The approval card must show Release ID, preview, version/hash, channel, market, claim links, rights expiry and decision consequence. Microsoft says approvers may respond through email, Teams or the approvals center. Those surfaces are interfaces to the approval service; the flow should still preserve the returned response in the evidence list.

Stage 3: write evidence before status

On a response, create a new Approval Evidence item first. If that write succeeds, update Current status and Latest decision ID. If it fails, leave the release Pending or Exception and alert the flow owner. Do not publish merely because an email said Approved.

For “everyone must approve,” store each responder where the connector output makes it available, not only the aggregate result. For sequential approval, preserve the order and every outcome. Comments should be retained, but the asset hash is what binds the decision to a version.

Automation may check completeness, route by a governed matrix, wait, write evidence and create a release task. Humans decide. A high-risk item must not fall back to a first-responder approval because one approver is unavailable; route to an authorized delegate under policy.

Stage 4: release with a second check

The publishing flow or operator re-reads Release ID, Current status, Latest decision evidence, asset hash and rights expiry. If content changed, approval expired or a required responder is missing, stop. After publishing, write the platform ID and rendered URL, then set Released.

Permissions map:

• Requester: create and view own requests; cannot edit decision evidence.
• Approver: respond through the approvals service; read the asset.
• Release operator: read approved records and write release result.
• List owner: schema and controlled permissions.
• Flow owner/service account: connections and run monitoring.
• Auditor: read evidence and version history; no deletion.

SharePoint list permissions can be customized, but inherited access and privileged administrators matter. Use a dedicated site where appropriate. For regulated immutability, consult Microsoft Purview retention/records specialists rather than representing list versions as write-once storage.

Stage 5: handle duration, throttling and licensing

Long-running approvals, connector throttling and licensing can change architecture. Microsoft publishes Power Automate request and connector limits, and connectors may return HTTP 429 when throttled. Licensing depends on user, flow and premium-connector context. Confirm the tenant’s entitlements and design an exception path.

If an approval may exceed flow-run duration or organizational limits, use a durable pattern: create the approval, persist its ID and resume through a separate trigger or scheduled monitor according to current Microsoft guidance. Never hide a timed-out approval by starting an unlinked replacement.

Failure test suite

Test rejection, changes requested, absent approver, duplicate trigger, asset edit after approval, expired rights, approval success followed by evidence-write failure, list update throttling and a release response lost after external publish. Each should produce a visible Exception or stopped state, never silent approval.

Attempt to edit and delete an Approval Evidence item using requester, approver, owner and administrator roles. Record the real boundary. Restore a list version and confirm Latest decision ID still reconciles. Capture screenshots of schemas, permissions, flow branches, approval card, evidence record, failed run, retry and release verification. CDM has not executed these tenant-specific tests.

Worked item: illustrative product-claim email

• Release ID: MKT-REL-00681
• Asset: Q4 retention email, HTML version sha256:47a9…
• Channel/market: customer email, United Kingdom
• Risk: product performance claim
• Evidence: CLM-1042 / EV-287
• Rights expiry: not applicable
• Approval policy: Product Marketing and Compliance, everyone must approve
• Responses: two Approved events with comments and timestamps
• Decision evidence: APR-01291, linked to the submitted hash
• Status: Approved, pending release check
• Release result: illustrative provider message ID written after send

Changing the subject line or claim body changes the version and requires a new evidence item; the earlier approval remains historical.

Release evidence checklist

Before operators act, the evidence view should show one request, one exact asset hash, the required approval policy, every expected responder, one aggregate outcome and no later edit. The release action should add destination, platform identifier, rendered URL, operator and timestamp. Reconcile exceptions daily during active campaigns. A missing response, duplicate event or changed hash keeps the item stopped; an administrator must not repair the record by overwriting its history.

Related guides

• How Do You Turn Slack Marketing Decisions Into Durable Records?
• How Do You Add Human Approval Before Zapier or Make Publishes Marketing Content?

Frequently asked questions

Is Power Automate approval history enough on its own?

Not for a complete marketing trail. The approval service records responses, but the business needs a stable join to Release ID, exact asset version, risk, rights and publication result. Append the response to a controlled evidence list and retain the approval service and flow-run identifiers.

For ordinary low-risk work, the standard history may satisfy operational needs; regulated or litigable material requires a records specialist to assess retention, access and legal-hold controls. Test export and retrieval before approving the retention design.

Is Microsoft Lists version history immutable?

No. Version history is valuable for reconstruction, and new lists commonly have versioning enabled, but Microsoft documents permissions that can delete versions. Do not call it immutable. Restrict those permissions, use a separate append-only event design and assess Purview retention or another records system when alteration resistance is required.

The caveat is risk proportionality: a routine social resize does not need the same retention architecture as a regulated financial promotion. Document the residual administrator power in the control assessment. Review it annually.

Which approval type should we choose?

Choose from the decision policy: first response for one-of-several authorized equivalents, everyone must approve for independent required functions, or sequential approval where later reviewers depend on earlier judgment. Do not choose the fastest card for convenience. Custom responses can capture Changes requested, but define their consequences.

The exception is emergency response, where an approved incident policy may permit a smaller quorum; record the policy and retrospective review rather than silently weakening the normal route. Test each route using representative approver accounts.

What if the approver responds by email?

That is acceptable when the response is captured by the Microsoft approval action and tied to the correct approval ID. Email is then an interface, not the record itself. Preserve the connector’s returned actor, outcome, time and comments in Approval Evidence.

A forwarded or manually typed “approved” email outside the action should not release content. If the approval card or connector is unavailable, use a documented alternate decision process and record it explicitly. Verify mobile and delegated-mailbox behavior before relying on them.

How do we stop duplicate approvals or releases?

Use Release ID and correlation ID as idempotency keys, restrict state transitions and check for existing evidence before creating another event. Before publishing, query for a platform result and confirm the exact asset hash. Duplicate triggers should converge on one pending approval or stop as exceptions.

If the destination cannot be queried after a timeout, require manual reconciliation rather than replaying blindly. Idempotency must cover external publication, not only SharePoint item creation. Log every suppressed duplicate for operational review. Investigate recurring causes.

Who should own the flow connection?

Use an organizationally managed account or service principal pattern supported by the connectors and tenant policy, with named human owners and offboarding procedures. A departing employee’s personal connection can disable a critical approval route. Apply least privilege, rotate secrets and monitor failures.

Some connectors or actions may not support every service-account design, and licensing context matters; the Microsoft 365 administrator should validate the chosen ownership model before production. Assign a backup owner, document renewal dates and test takeover annually in staging.

Next decision: Build a modern content supply chain

Related reading: Design creator content approvals · Correct an unapproved AI-generated claim · Create a marketing experimentation system

Sources and research notes

• Microsoft Learn, Get started with approvals and Approvals connector reference.
• Microsoft Learn, Build approval flows.
• Microsoft Support, How versioning works in lists and libraries.
• Microsoft Learn, Power Automate limits and Licensing FAQ.

Research checked 26 September 2026. CDM reviewed official documentation but did not access a Microsoft 365 tenant or run approval, permission, throttling or exception tests. Licensing and tenant policy require administrator verification. The sample is illustrative; “immutable” retention claims require records-management and legal review.