Start with the decisions the work supports
A source-of-truth map begins with the decisions the workflow supports, not with the tools the team uses. Name the decisions, such as whether to approve a refund, schedule a visit, or renew a contract. For each decision, list the facts a person must trust. The map then shows where those facts come from.
Separate a fact from an opinion or a convenience copy. A signed contract is a fact source, while a summary slide is a convenience copy. A customer record in the CRM may be the source for contact details, while the billing system is the source for payment status. Write the distinction beside each fact so the team does not argue from the wrong copy.
Mark the decisions that are high risk if the fact is wrong. A payment detail, an access grant, and a clinical instruction belong in that group. Give those facts a stricter source and a named verifier. The map should spend its detail where a wrong fact would cause real harm.
Name the owner of each field
Every field needs a system owner and a business owner. The system owner controls how the field is stored and who can change it. The business owner decides what the correct value means for the work. A field with only a system owner often drifts because no one is accountable for its meaning.
Write the allowed update path for each field. Some fields may be edited directly, while others require a request and an approval. A bank detail may need a second verifier, and a legal name may need a document check. The assistant should know which path applies before touching the record.
Name the person who can approve a correction and the evidence they need. A correction without evidence is a guess that becomes permanent. Require a source link, a screenshot, or a signed document, depending on the field. Store the evidence with the change record so a later reader can follow it.
Identify the copies that cause trouble
List the copies that people actually use: exported spreadsheets, saved reports, email threads, and personal notes. A copy becomes dangerous when it looks authoritative and no longer matches the source. Mark each copy with its refresh date and its owner. Retire the copies that no longer serve a purpose.
Decide which copies are allowed and which should be retired. A working copy may be fine for a short task if it is clearly labeled and deleted afterward. A standing copy that people treat as the record should be replaced by a link to the source. Fewer copies usually means fewer conflicts.
Check the places where two systems overlap. A contact may exist in the CRM, the inbox, and the billing tool. A project may have a status in the task board and a different status in the client report. Write down which system wins and how the other is updated. The overlap is where most rework begins.
Test the map with real cases
Pick five recent cases where someone had to check a fact twice. Trace the fact back through the systems and copies used. Record where the values differed and which one the team treated as correct. The cases show whether the map matches practice rather than intention.
Ask the assistant to find one field without help. Time the search and note which system they opened first. If the first stop is a convenience copy, the map has not made the source obvious. Fix the labeling or the link rather than blaming the assistant for the habit.
Compare the map with the access list. A person who can edit a field should appear as an owner or an approved editor. A person who only needs to read should not have edit rights. The comparison often reveals access that was granted for an old task and never removed.
Keep the map current
Give the map a review date and one owner. Review it when a system changes, a client changes, or a new role joins the workflow. A map that is reviewed only at launch becomes a description of a process that no longer exists. Put the review on the same calendar as the access review.
Record changes in a short history rather than editing the map in silence. Note the date, the field, the old source, and the new source. A history helps the team understand why a report changed and who approved it. It also makes a later audit much easier.
Keep the map short enough to use. One page per workflow is usually enough if it names the decisions, the fields, the owners, and the copies. Put the detailed system notes in an appendix. A map that requires an hour to read will not be consulted during a busy day.
Set the boundary for the assistant
The assistant may read the map, check a value, and prepare a correction request. The business owner should approve a change to a sensitive field. Write that boundary in the role brief and in the map itself. A clear boundary prevents an assistant from fixing a record that should have been escalated.
Define what the assistant must do when two sources disagree. The default should be to stop, preserve both values, and send the case to the field owner. Do not let the assistant choose the more convenient value. A disagreement is evidence that the process needs attention, not a guess to be resolved quietly.
Review one field and one copy each month. Retire a copy that no longer has a purpose and confirm that the source still matches the work. Small, regular maintenance is easier than a full rebuild. The goal is a map the team trusts enough to use when a decision is urgent.
Sources
Open the original publisher and confirm the current version, definition, and scope before using a source for a business decision.
Turn the reading into a role brief
Bring the recurring tasks, tools, schedule, access limits, and owner-only decisions. Start with one work sample and one clear review path.
Plan a Philippines-based role