Home · Solutions · Legal & compliance

Solution · Legal & compliance

The gaps in your bulletin should be found by the office, not by a journalist

The bulletin that notices what is missing from it

Robots compare the bulletin against the registers that produce its content and hand every gap, stale file and superseded version to the editor who owns it.

Quick winMicrosoft TeamsHuman in the loopDeterministic automation
260entries make up the publication list of this illustrative municipal office, and fourteen units keep them current between other duties.

Executive summary

Challenge

Gaps in the bulletin are found by a resident, a journalist or an inspector, never by the office itself.

What changes

The first thing we deliver is not software.

Business value

The monthly review stops consuming unit time and becomes a report read in minutes.

Systems involved

SharePoint evidence record and prepared entries; Power BI report; the bulletin platform, read-only

Business problem

Publication duty

A public bulletin is the one place where an office speaks to everybody on the same terms. The duty sits with the office as a body, while the work is spread across every organisational unit and subordinate entity, each publishing what it produces through its own editor. Responsibility for the whole is nobody's daily task.

Currency fails before completeness does. A resolution is amended, a procedure reissued, a contact list changed, and the new file goes up beside the old with nothing linking the two. Editors move between posts and take the only record with them, so a successor inherits pages, not a schedule.

At fourteen publishing units the failure mode becomes predictable. The office learns the size of its gap from outside: an information request that a findable document would have prevented, a journalist comparing the bulletin with a register, an inspector working a checklist. Each lands as an urgent case on a busy unit.

How it works today

This is what we find before anything is automated, whatever platform the bulletin runs on.

  1. PersonA unit's editor receives a document from whoever produced it, by email or from a shared drive
  2. PersonThe editor opens the editing screen, creates or replaces an entry and picks the category by habit
  3. WaitingDocuments arriving late in the week wait for the editor's next quiet hour, often several days
  4. Risk of errorAn amended document goes up as a new file while the superseded version stays online, nothing linking the two
  5. PersonOnce or twice a year, before an inspection, somebody walks the bulletin page by page from memory
  6. Risk of errorBetween those reviews the gaps surface from outside: an information request, a journalist, an auditor's sample
PersonWaitingRisk of error

Why the current process costs more than it appears

Time that disappears before anyone measures it.

  • Nobody owns the whole list, so the review that would find the gaps is the task no unit must perform, and it loses every week to work with a deadline.
  • Every gap a resident finds becomes an information request, which carries a clock, a register entry, a search across units and a written answer: the office pays twice for one document.
  • Superseded documents cost more than missing ones. A resident who acts on a withdrawn version has been misinformed by the office, and correcting that takes a complaint and an explanation.
  • Editor turnover erases the only record there is: handover notes describe the tool rather than the duty, so each successor starts again and the interval resets to zero.

Cost of inaction

Twelve months of checking the bulletin by hand≈ €21,736
The same checking across a three-year inspection cycle≈ €65,200
If the catalogue grows to 340 entries (per year)≈ €28,400

Fourteen units publishing to one bulletin without a shared list drift one way. Each month a few documents are amended and not replaced, a few new duties land on a unit that does not yet know them, and nothing reverses it. The office learns the size of the problem when somebody outside counts.

What the rows cannot price is the second queue: a resident who cannot find a document files a request instead, answered inside a clock, with a register entry, a search and a signature.

Illustrative scenario

A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.

Organisation

A municipal office of about 340 staff with fourteen publishing units, organisational and subordinate; Microsoft 365 in daily use, the bulletin on a platform hosted by an external supplier.

Volume

260 entries on the office's publication list, reviewed monthly; about 30 new or amended documents a month arrive from registers the office keeps: resolutions, decisions, contracts, budget and recruitment.

Current process

Each unit publishes when its editor has an hour. What the bulletin should contain is written partly in an instruction, partly in one person's spreadsheet, and partly nowhere.

Bottleneck

About 22 minutes an entry: open the source system, find the current version, compare it with the published page, note the outcome. Nothing records the check, so each reviewer starts fresh.

Solution

Scheduled robots read the publication catalogue, compare each entry against its source and against what the bulletin shows, and classify every difference. Each finding becomes a task in Microsoft Teams for the named editor; the editor releases, the robot never publishes.

Potential outcome

In the modelled case the monthly review becomes a report, differences surface within a day of a source document changing rather than at the next inspection, and roughly 95 hours a month return to the units. The figures are a model, not a measurement.

Proposed solution

The first thing we deliver is not software. It is the publication catalogue: one row per entry with its category, owning unit, named editor, source system, review interval and the rule that decides what current means. What the bulletin should contain stays the office's own determination; the ingredients usually exist already, scattered across an instruction, a spreadsheet and two people's experience.

A scheduled robot then does what a diligent person would do with unlimited patience. For each row it takes the current document from the source register with its version and date, retrieves the matching bulletin page, and compares three things: whether the entry exists, whether the published version is the one the source holds, and whether its date falls inside the office's interval. Every difference is classified as missing, stale, superseded or orphaned and written to an evidence record on SharePoint.

Findings land where the editors already are: a short list in Microsoft Teams with the source document attached and the reason in one line, on the office's reminder schedule rather than anyone's memory. One boundary is deliberate. The robot prepares, a person releases; no robot account can publish, and the decision that a document may go out stays where it is.

Native capabilities used

UiPath Orchestrator time triggers, queues, retries and audit logs; UiPath Integration Service connectors for Microsoft OneDrive & SharePoint and Microsoft Teams; SharePoint version history; Power BI in a Microsoft Teams tab

What we build

The catalogue and its rules, the comparison logic per source, the finding taxonomy, editor tasks and reminders in Teams, the evidence record and the gap report

Custom integration

Read-only access to the source registers through an API where one exists and through the application's screens where none does; no write access to the bulletin platform

How the automated process works

  1. AutomationA time trigger in Orchestrator turns the catalogue into the run's comparison queue, one item per row
  2. SystemThe robot opens the source register named on the row and takes the current document, its version and date
  3. AutomationIt retrieves the bulletin entry and compares presence, version and date against the category's rule
  4. AutomationDifferences are classified, ranked and written to the SharePoint evidence record with the comparison proof
  5. PersonEach finding becomes a task in Microsoft Teams for the named editor, with the source document attached
  6. PersonThe editor checks the prepared entry and publishes it under the office's release rules
  7. AutomationThe next run re-checks it, closes the finding once the versions match, and refreshes the report
AutomationSystemPerson

Human-in-the-loop model

Automation handles

  • Running the comparison on schedule across every entry, every unit and every subordinate entity
  • Reading source registers and published pages, and classifying each difference
  • Raising, routing, reminding and closing findings, and recording the evidence

People decide

  • What belongs on the catalogue, in which category and at what interval. The list is the office's; a robot applies it
  • Whether a document may be published, in what form and with what removed. The robot holds no publishing rights
  • Whether a finding is real. A document may be lawfully absent or already replaced, and the editor records the reason

Before and after

BeforeAfter
Checking time per entry~22 minseconds where the entry matches, minutes where it does not
Time from a source change to the difference being noticedthe next full review, or a question from outsidethe next scheduled run
Evidence that a check happenedthe published page, nothing morea dated record naming the version compared
Who finds the gapsa resident, a journalist or an inspectorthe office

Systems and integrations

Where a rule suffices we do not use a model. Where judgement is needed, a person decides.

Inputs

  • the catalogue on SharePoint
  • the resolution and decision registers
  • the contract register
  • the budget system
  • the recruitment system
  • published bulletin pages

Automation layer

  • UiPath Orchestrator
  • UiPath Robots
  • UiPath Integration Service

Target systems

  • SharePoint evidence record and prepared entries
  • Power BI report
  • the bulletin platform, read-only

Human touchpoints: editor findings in Microsoft Teams; the gap report in a Teams tab; release in the bulletin's editor

the catalogue on SharePointUiPath OrchestratorUiPath RobotsSharePoint evidence recordeditor findings in Microsoft Teams

Technologies used

UiPath Robots + Orchestrator

run the comparison on a time trigger, queue each row, retry and log

A
UiPath Integration Service (Microsoft OneDrive & SharePoint, Microsoft Teams connectors)

read the catalogue, file evidence, post editor tasks

A
Microsoft SharePoint

holds the catalogue, the evidence and the prepared entries, versioned

A
Microsoft Teams

each editor sees their own findings; the manager opens the gap report

A
Power BI

backlog by unit, age of findings and release timeliness, in a Teams tab

A
Source registers and the bulletin platform, read-only

supply the current document, version and date; the page is read, never written

C
Averified product capability (vendor documentation)Cillustrative model — the figures on this page

Illustrative economic model

Start by questioning the assumptions.

Illustrative model
260 catalogue entries × 22 minutes of checking≈ 95 h / month
95 h × €19 fully loaded hourly cost≈ €1,811 / month
× 12 months≈ €21,736 / year
Annual capacity returned to the units (illustrative)≈ €21,736

The arithmetic below prices a duty, not a saving: 260 catalogue entries reviewed each month, 22 minutes to check one properly, and €19 an hour as a fully loaded cost of an administrative post. None was measured in an office; each is stated so it can be replaced. What comes out is capacity returned to the units, never a headcount number.

Run the numbers on your data

hours released per month
of annual capacity released

An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.

Business benefits

  • The monthly review stops consuming unit time and becomes a report read in minutes
  • A difference is raised within a day of the source changing, so a resident finds the current version, not the withdrawn one
  • Every check leaves evidence: what was compared, against which version, on what date, and who released the entry
  • The same standard covers all fourteen units, so what a resident finds no longer depends on which unit produced it

The management view

  • The office manager can say on any day how much of the bulletin is current and which unit is behind
  • Publication becomes a measured duty with named owners rather than a matter of each editor's diligence
  • Findings age visibly, so an overdue entry escalates by itself instead of waiting for an inspection to find it

Board-level KPIs

entries verified currentmedian age of an open findingfindings raised from outsidedays from source document to published entry

Security and governance

The automation holds exactly the rights it needs, and not one more.

  • The robot holds read rights and nothing else: no account of its own can publish, which the office can inspect rather than take on trust
  • Source registers are reached through technical accounts scoped to them, granted under the office's own access rules
  • Catalogue, findings and evidence stay in the office's Microsoft 365 tenant; the robots run from the EU region of UiPath Automation Cloud
  • Every run writes what it compared, against which version and when, to the Orchestrator audit log and SharePoint
  • Anonymisation before publication stays a human act; the comparison reads presence, version and date

Why now

01

Correspondence with offices has gone digital at scale: the Ministry of Digital Affairs reported on 5 August 2026 that e-Doręczenia had passed 100 million items and 4.6 million addresses in the Base of Electronic Addresses. A resident who files everything electronically reads the bulletin the same way, and notices a version older than the one they were sent

02

The manual half of this problem prices itself at roughly €1,811 a month in the model above; the other half arrives as information requests, complaints and pre-inspection reconstruction, which no budget carries

03

Nothing here needs a new platform: scheduled robots, read-only connectors into SharePoint and Teams and a Teams-tab report are ordinary today, so the work is agreeing the catalogue

Relevant executive roles

Secretary of the office

Publication becomes a controlled duty with named owners and a record, not fourteen habits and one shared reputation

Head of an organisational unit

Editors get a short specific list rather than an annual page-by-page review, on the same rule as everyone

IT lead

One scheduled read-only integration and a report, not a portal to buy, host and secure

Head of internal audit

What was published, when, and against which version can be sampled at any time

Common questions and objections

Our units publish different things; one list will never fit them all.

The catalogue is built per unit, and each row carries its own source, rule and interval. What is shared is the mechanism, not the content, so fourteen practices sit on one list unflattened.

We will not have a robot publishing on our bulletin.

It does not publish. The robot reads and prepares the entry; the editor releases it under the rules the office already applies. The value is the comparison and the evidence.

Some of our registers have no interface a robot can read.

Several will not, and those are read as a person reads them, on screen: slower, but still scheduled and recorded. Where nothing can be read, the row keeps a manual check and a reminder.

When this is not the right solution

  • An office with two publishing units and a short list, where one owner and a calendar do the job for less
  • An office that has not decided what its bulletin should contain, because the catalogue is a decision no automation can take for it
  • Where source documents exist only on paper, so the registers come before any comparison

A question for the next management meeting

How often does this office compare its own bulletin against the registers that feed it, and could we produce the date of the last comparison for every entry?

Implementation approach

We start with one slice of the process and extend only once it is proven.

We deliver

  • A workshop with the units that builds the catalogue: entry, category, owner, editor, source, interval
  • Comparison rules per source: what is current, what is superseded, what may lawfully be absent
  • Robots, schedules, the finding taxonomy and the evidence record on SharePoint
  • Editor tasks, reminders and escalation in Teams, and the Power BI gap report
  • A pilot on two or three units, then rollout with hypercare and a runbook

We need from you

  • Whatever describes the duty today: an instruction, a spreadsheet, a handover note, past findings
  • A named editor per publishing unit and one owner of the catalogue
  • Read-only technical accounts for the registers and the bulletin

Stages

Catalogue

Build the list of what the bulletin owes, with the owner of each row

Rules

Agree what current, stale and superseded mean per category

Build

Comparison robots, findings, Teams tasks and the evidence record

Validation

Run against the live bulletin silently, and confirm findings with the units

Go-live

Start with the pilot units, extend unit by unit, with hypercare and tuning

Quick win. Effort follows the number of source systems and whether they expose an interface, not the entry count.