I85PREP
⌘ K
Appian Certified Analyst study materials
Appian Certified Analyst study resources

The Record That Everyone Edits and Nobody Trusts

Appian Certified Analyst · Put your knowledge to work in context.

All case studies

The Record That Everyone Edits and Nobody Trusts

A customer record is built from three sources: a CRM sync, a manual entry form, and a nightly batch import. The record type has 60 fields. Users report that a phone number updated in the UI reverts the next morning, and a segment field sometimes shows two different values on two different pages. There are 14 process models and 30 interfaces reading and writing the record. No one can say which source is authoritative for which field. A recent audit found that 8% of records have a last-modified-by of a service account, making it impossible to trace who changed what.

1. Explain the likely causes of the reverting phone number and the inconsistent segment field, and propose a data ownership model.

Read the worked answer

Reverting phone number. The nightly batch import is overwriting the manual edit. The UI write succeeds, but the batch treats its source as authoritative for phone and blindly updates the field each night. This is a write-conflict / last-writer-wins problem, not a UI bug. Confirm by checking whether the batch runs a full update on all fields versus a delta on changed fields.

Inconsistent segment field. Two pages likely read the value at different times or from different contexts - e.g., one reads a cached/local variable populated at load, the other queries fresh. If the batch and a process also write segment, the two views can legitimately disagree mid-flight. This is a read-consistency and multiple-writer problem.

Data ownership model. Assign, per field, a single system of record and a write policy:

  • CRM-owned (phone, email): batch and UI must not overwrite; UI edits route to CRM or are read-only locally.
  • App-owned (segment, internal flags): external syncs are read-only inputs, never direct writes.
  • Manual-only fields: protected from batch entirely.

Document this as a field-level ownership matrix, enforce it in the sync logic (only update owned fields; skip or flag conflicts), and add a source/last-updated-by stamp per field group so conflicts are visible rather than silent. Route UI edits of externally-owned fields through the owning system.

2. How would you make changes traceable, given 8% of records show a service account as last modifier?

Read the worked answer

The service-account problem means process and integration writes are anonymized - the platform records the technical user, not the human or cause. Fixes:

  1. Capture the acting user explicitly. When a process writes on behalf of a person, store the initiating user in a field (e.g., lastChangedByHuman) rather than relying on the system audit field. Pass the original user through the process context.
  2. Tag the write source. Add a changeSource field (UI / CRM sync / batch / process name) stamped on every write, so a service-account change is at least attributable to a cause.
  3. Use process/integration logging to record what each batch and process changed, with a correlation ID linking the log entry to the record.
  4. Reduce blind writes. Make the batch a delta update (only changed fields) rather than a full overwrite, so it stops clobbering manual edits and the change log shrinks to real changes.
  5. Audit review cadence. Because platform audit history shows the service account, rely on your own stamped fields plus process logs for human-attributable history; reconcile them periodically.

Net: don't trust the built-in last-modified-by alone when automation writes. Stamp human identity and source on every write path, and make batch writes minimal and logged.