FOIA delays and redaction stalled publications — SharePoint & Power Automate approvals

Overview

A government agency’s strategic plan updates slowed because documents moved through rigid routing, versions diverged in email, and Freedom of Information Act (FOIA) concerns delayed public releases. Teams spent cycles redacting content by hand and tracking approvals in spreadsheets. Intelligex stood up a SharePoint-centered workflow with managed metadata, automated redaction and sensitivity labeling, and an approvals trail tied to roles. A lightweight dashboard showed status and upcoming releases, and Legal reviewed flagged items before publication. Leadership gained transparency, fewer bottlenecks, and safer public communications because every update referenced the same governed artifacts with a clear approval path.

Client Profile

• Industry: Public sector (executive agency)
• Company size (range): Multi-division organization with regional offices
• Stage: Ongoing strategic planning and annual public reporting cycle
• Department owner: Strategy, Analytics & Executive Leadership (Office of Strategy and Performance)
• Other stakeholders: General Counsel/FOIA Office, Communications/Public Affairs, Program Directors, Records Management, IT/Security, Privacy, Finance

The Challenge

Strategic plan updates had to consolidate inputs from programs and regions, route for review, and publish public-facing summaries. In practice, drafts lived as Word and PDF attachments, track changes broke across versions, and approvals were gathered in email. FOIA and privacy concerns required careful review and redaction, but sensitive details appeared late in the process. Public Affairs often waited on Legal to clear language, while Legal struggled to trace what changed and why. When releases slipped, leadership lacked a single view of where content was stuck.

Tools were in place—SharePoint for document repositories, email for routing, and a shared calendar for publication dates—but there was no governed process to tag content, identify sensitivity, route to the right approvers, and record decisions. The agency needed to keep content in SharePoint while adding automation for metadata, redaction, approvals, and a transparent status view.

Why It Was Happening

Routing and evidence were fragmented. Drafts moved via email with ad hoc filenames, so reviewers operated on different versions. There was no shared taxonomy for topics, programs, or sensitivity, and FOIA considerations surfaced late in Public Affairs. Redactions were performed manually on exported PDFs with no durable link back to the underlying approved text.

Governance came at the end. Approvals were captured in comments or meeting notes rather than a system with roles, timestamps, and reason codes. There was no standard to confirm that required reviews occurred before release, no audit trail to support FOIA responses or records retention, and no oversight of which content was ready for public posting.

The Solution

We implemented a SharePoint-based operating layer for strategic plan updates that standardized metadata, automated sensitivity detection, and formalized approvals. Authors worked in SharePoint libraries with managed metadata and content types; policy checks flagged sensitive phrases and entities; redaction was applied during export for public release; and a Power Automate approval captured Legal, Privacy, and Communications sign-off with an audit trail. A status view made bottlenecks visible. Nothing was replatformed: SharePoint remained the source of documents, Outlook and Teams stayed in use for collaboration, and the new flow orchestrated tagging, review, and release.

• SharePoint libraries with managed metadata and content types for program, topic, sensitivity, and publication target (SharePoint Managed Metadata)
• Automated sensitivity detection and labeling using Microsoft Purview policies and data loss prevention (DLP) (Microsoft Purview DLP, Sensitivity labels)
• Redaction workflow for public disclosure exports via eDiscovery review sets and policy-based masking (Microsoft Purview eDiscovery (Premium))
• Approval gates in Power Automate capturing Legal/FOIA, Privacy, and Communications sign-offs with comments and change logs (Power Automate Approvals)
• Role-based access through Microsoft Entra ID groups for author, reviewer, approver, and publisher roles (Microsoft Entra groups)
• FOIA-ready publication package with version-stamped source, redaction rationale, and release artifacts aligned to FOIA guidance
• Power BI dashboard embedded in SharePoint to show pipeline status, pending approvals, and upcoming release windows (Power BI)
• Audit logging for access, label changes, approvals, and exports via Purview audit features (Microsoft 365 audit)
• Change-control process for metadata schema, sensitivity policies, and approval routing with documented owners

Implementation

• Discovery: Mapped current drafting and routing steps, cataloged document types and repositories, and identified mandatory reviews. Collected recent FOIA redaction cases and publication delays to understand failure modes. Reviewed records retention and audit requirements with Legal and Records Management.
• Design: Defined the content types, managed metadata, and sensitivity taxonomy. Authored DLP rules and label policies, and configured redaction behaviors for public exports. Designed the approval workflow and role mappings. Planned the dashboard views and audit fields to evidence who approved what, when, and under which policy.
• Build: Configured SharePoint libraries with content types and metadata, set up Purview DLP and sensitivity labels, and implemented eDiscovery review sets for redaction. Built Power Automate flows for stage-wise approvals with comments and attachments. Published Power BI status views and integrated audit log reporting.
• Testing and QA: Ran historical documents through the pipeline, validated metadata tagging, sensitivity detection, and redaction output. Dry-ran approvals with Legal, Privacy, and Communications to exercise comments and escalations. Verified audit stamps for access, label changes, approvals, and export events.
• Rollout: Launched in parallel with the existing email-driven process for one publication cycle. After validation, made SharePoint the system of record for drafts, required metadata and approvals, and exported public packages via the redaction workflow. Maintained an exception path for urgent releases with post-publication review.
• Training and hand-off: Delivered quick guides for authors on metadata and sensitivity labels, for approvers on reviewing and commenting in the flow, and for Communications on assembling publication packages. Assigned stewardship for taxonomy, DLP policies, and approval routing with a change-control cadence.

Results

Strategic plan updates moved through a visible, governed pipeline. Authors worked against a common template with required metadata; sensitive terms and entities were flagged early; and approvals captured comments and decisions in one place. Redaction happened as part of the export process rather than as a manual last step, and the public release package linked back to the approved source.

Leadership saw where drafts sat, which teams owed reviews, and which releases were ready. FOIA and privacy considerations were handled consistently, supported by audit logs and version stamps. Public Affairs spent less time reconciling redlines and more time on message quality. The agency felt confident that public communications matched approved language and that records supported inquiries.

What Changed for the Team

• Before: Drafts circulated by email with unclear versions. After: SharePoint hosted single-source drafts with managed metadata and content types.
• Before: Redactions were manual and late. After: Sensitivity labeling and policy-based redaction ran before public export.
• Before: Approvals were tracked in spreadsheets and inboxes. After: Power Automate captured sequential sign-offs with comments and audit stamps.
• Before: FOIA concerns surfaced at publication. After: DLP and Legal review gates flagged issues earlier in the flow.
• Before: Leaders lacked status visibility. After: A dashboard showed pipeline health, pending approvals, and ready-to-release items.

Key Takeaways

• Keep content in SharePoint; layer metadata, sensitivity policies, and approvals to govern how drafts become public releases.
• Automate detection and redaction of sensitive content; handle privacy and FOIA risks before publication, not in the final export.
• Make roles explicit with stage-wise approvals and audit logs; governance is strongest when it is visible and routine.
• Standardize content types and tags so teams speak a common language and can find, route, and publish consistently.
• Provide a status view that spans drafting to release; transparency reduces bottlenecks and shortens review cycles.

FAQ

What tools did this integrate with?
We centered the workflow in SharePoint with managed metadata (Managed Metadata). Approvals ran in Power Automate. Sensitivity labeling and DLP policies were configured in Microsoft Purview (DLP, Sensitivity labels), with disclosure exports handled via eDiscovery (Premium). Role-based access used Microsoft Entra groups, and pipeline status surfaced in a SharePoint-embedded Power BI report.

How did you handle quality control and governance?
We enforced required metadata and content types, applied DLP and sensitivity labels to flag and protect sensitive content, and routed drafts through defined approval gates for Legal/FOIA, Privacy, and Communications. Redaction occurred within a controlled export process, and audit logs recorded access, label changes, approvals, and releases. FOIA requirements guided what was disclosed and how exemptions were applied (FOIA).

How did you roll this out without disruption?
We ran the SharePoint workflow in parallel with the legacy email-driven process for a cycle, compared outputs, and tuned labels and routing. After teams were comfortable, we set SharePoint as the system of record for drafts and made approvals and redaction part of the standard path. An exception lane remained for urgent releases with post-publication review.

How did you address FOIA redaction and public release?
Sensitive content was identified via DLP and sensitivity labels, then reviewed by Legal/FOIA as part of the approval gate. Public exports used a redaction workflow in eDiscovery to generate a release package with masked content, citations to the applicable exemption, and a link back to the approved source for audit. The package and rationale were stored alongside the version-stamped draft for future reference.

How were permissions and auditability managed?
Microsoft Entra groups governed who could author, review, approve, and publish. Audit logs tracked view and edit access, label and policy changes, approvals, and exports (Microsoft 365 audit). Role-based views in SharePoint ensured that only authorized users could see sensitive drafts, while the public release library exposed redacted, approved versions for broad access.