Skip to content
Book a discovery call

A weekly report with the gaps left visible

Illustrative worked example using fictional information. This is not a client case study or a claim about a live integration.

A reporting workflow should help the reviewer see what is known and what still needs checking. This example follows a small set of job updates through that process.

Without Propel

Job A: complete

Job B: no update

Job C: statuses conflict

With Propel

  1. Keep the sources
  2. Show the exceptions
  3. A person checks it

The information going in

Fictional job updates
Job A · complete
Job B · update missing
Job C · sources disagree

The fictional team has three records to review.

  • Job A has a completed status and a matching completion update.
  • Job B has an in-progress status, but no current update from its owner.
  • Job C is marked complete in a spreadsheet, while a later message says it is waiting for a part.

The report needs to preserve those differences. A neat summary that describes every job as on track would be misleading.

What the draft should say

Job A

Reported complete. The status and completion update agree.

Job B

Current update missing. The reviewer needs to check with the owner before relying on the status.

Job C

Conflicting information. The spreadsheet and later message disagree. Confirm the current position before publishing.

What the reviewer should be able to do

  1. Check the sources
  2. Resolve exceptions
  3. Approve the report

Open the source for each reported fact, correct an error and decide which unresolved items belong in the final report.

The workflow should make review easier without hiding uncertainty. Preparing a draft does not give the system permission to send it to customers or change the original records.

What a real build would need to prove

Checks to specify
Missing & duplicate inputsPermission failuresA manual fallback

The implementation needs tests for missing and duplicate updates, contradictory records, permission failures and unavailable source systems.

It also needs to handle instructions embedded in source material as content, rather than let them change the workflow's rules. Failed processing must be visible, and the team needs a manual fallback.

These are requirements to test. This written example is not evidence that a production system has passed them.

Apply the example to your reporting process

Which inputs would your report need? Who would check it? What information could not be shared with every recipient?

Those questions help define whether a reporting build is useful and how it should work.

Discuss your reporting processExplore reporting automation