Master Data — Temporal Workflows Proposal

0 · Read first — the one correction that changes the design

And on what "Standard vs Customized" even means — the commercial team's role is upstream and external:

Net effect on the workflows: I've deleted the commercial_lead_decision signal and the upstream CL branch entirely. There is exactly one approval stage — the Data Team — for every flow, which is what Emily confirmed in the questionnaire (Part B Q1–3). The STD/CUS distinction only changes how the request arrives and what must be attached, not who approves in the tool.

1 · Who actually uses the tool

Three buckets. Only the first bucket fires workflow signals.

① Active — these roles operate in the tool (fire signals)

② Read-only — in the tool, but no workflow gate

③ External — do not operate in the tool

2 · Why Temporal (in plain English, for non-engineers)

The website is great at a single click: submit a form, edit a cell, approve a record. It is bad at the thing in between — a spec that is born from a request, waits on the Data Team, waits on a Factory in another timezone, gets rejected and resubmitted, then finally syncs to SAP — over days, touched by several people, where any step can stall.

Temporal is the tool for exactly that. Each flow becomes one durable workflow that:

• Waits for a human for free. While parked waiting for the Data Team to review, it uses zero resources and survives restarts/crashes — no cron, no polling.
• Retries the flaky bits (SAP push, email) automatically.
• Is its own audit log. Every state change is recorded as history — the "who changed what, when" Emily asked for, built in.
• Fires the SLA alert Emily wanted ("alert the Data Team if not reviewed within N days") as a durable timer, not a fragile scheduled scan.

The website starts a workflow and signals it (every approve/reject/submit click is a signal). The workflow calls back into the website's API and SAP via activities. The permission matrix still decides who may fire which signal — Temporal sequences already-authorized actions, it doesn't replace login/authz.

3 · The signal contract — the seam between website and Temporal

This is the most important table for the build: it is the interface all three layers agree on. The clickable demo simulates exactly these signals. Pin this early and the data/Temporal/UI layers can be built against it independently.

4 · The workflows

Six things genuinely deserve a durable workflow; a few more are candidates I'd argue against (§4.8). Diagram legend:

4.1 · NewSpecWorkflow — ideation → SAP sync core

The richest flow, and the one Emily drew on 12 Jun. Note: the submitter raises a request; the Data Team creates & completes the master record ("Data team turn to Create / revise SPEC"). STD/CUS only changes how it arrives + what's attached — same single approval.

4.2 · EditSpecWorkflow — change an existing spec core

The headline is cascade-with-exclude (Emily Part B Q7): when a SKU-level shared field changes, it must propagate to all that SKU's specs, with a confirm screen to tick off exceptions. This is the single biggest thing Airtable could not do.

4.3 · RetireSpecWorkflow — retire / delete core

Never a hard delete. Soft lifecycle status + SAP view-freeze, behind a guard (don't orphan sibling specs / open orders / on-hand stock).

4.4 · BatchUploadWorkflow — many new specs at once batch

Emily was firm: NPD won't enter records one-by-one ("they won't buy this idea"). A workflow that validates a whole Excel, reports row-by-row, lets the Data Team accept the valid rows, then fans out one child NewSpecWorkflow per accepted row — a natural Temporal pattern (durable validation + parent/child + partial accept).

4.5 · BatchEditWorkflow — edit many specs as one change batch

"The Airtable gap" Emily named: select many rows in a grid, change a field (e.g. case-pack / outer dimension), submit as one change request, reviewed once, applied across rows — with per-SKU cascade where the field is shared. (June-12: "batch update, batch create … only need to change the case pack, outer dimension.")

4.6 · SAP sync — integration activity / Jarry-dependent

Emily's flowchart has an explicit "If need Sync to SAP?" gate, then "if material exists → update master, else → create" and material-number-back + notify. Two shapes, decided by Jarry:

• Auto, per-record (default): sync_to_sap runs as the conditional tail inside each lifecycle workflow (a retried activity). Simplest; matches "approve → Ready → Synced".
• Manual / batched: a dedicated SapMassSyncWorkflow that the Data Team triggers ("Sync now"), gathers all Ready-for-SAP records, pushes them, and writes Material Nos. back. Matches the older "mass upload Airtable→SAP" idea.

I'll build it as a stubbed activity first (returns a fake Material No.) so nothing blocks on SAP access; the conditional structure is already known, only the mechanics (T-code ZMMR008, auth) are open.

4.7 · The shared spine (lives inside every flow — not separate workflows)

4.8 · Candidates I'd argue against making workflows scope guard

Listed so we can decide deliberately, not by accident. Default: plain CRUD / scheduled job, not Temporal.

5 · Build approach — and my honest critique of it

My plan: data layer → Temporal layer → UI layer. Here's where I think that's right, and where I'd amend it.

Two things to chase in parallel — they carry the most rework risk: (1) Emily's real end-to-end process-flow doc, and (2) 30 minutes with Jarry on SAP sync (auto vs manual, and is the write-back truly material-number-only). Don't block on them; do flag that deep work against guesses there is the most likely thing to be thrown away.

6 · Assumptions I'm making (correct me)

• One approval stage, always the Data Team, identical across new/edit/retire. (Confirmed in questionnaire; reconfirmed 12 Jun.)
• Commercial approval is an uploaded attachment verified by the Data Team, not an in-tool step. (The §0 correction.)
• The Data Team creates/completes the master record; other roles raise requests + provide info. (June-12 "Data team turn to Create".)
• Factory dimensions are a distinct human step after the spec is set, before SAP sync — modelled as its own signal/wait.
• SAP sync is conditional and the website is the source of truth; SAP returns only the material number. Auto-vs-manual is open (Jarry).
• "Shared (SKU-level)" vs "per-spec" comes from the Field Dictionary SKU (shared) / Spec (per-spec) column; that flag drives the cascade until Emily sends the explicit field list.
• The demo simulates signals client-side (no real Temporal cluster) — it's a design-validation artifact, deliberately not the real worker.

7 · Open questions for Emily / Jarry

1. Commercial approval mechanics (Emily): confirm it's an uploaded record/link the Data Team checks — and is it ever required for STD, or only CUS?
2. SAP sync (Jarry): auto-on-approve or manual "Sync now"? Is the write-back truly material-number-only? What fires "if need sync = no"?
3. Factory ↔ SKU link (Emily): how do we know which factory to notify for a given SKU? (Decides who notify_role(factory) targets.)
4. Retire guard data (Emily/Jarry): where do "open orders" and "on-hand MA stock" come from, so the guard can check them?
5. Cascade field set (Emily): the promised Excel of which SKU-level fields cascade on a shared-value change — still coming?
6. Sales/SP role (Emily): the grid says Sales = read-only, but the 12-Jun flow shows Sales/SP submitting CUS requests. Which is it?
7. Batch granularity (Emily): for batch upload, does the Data Team approve the whole batch at once, or row-by-row?
8. The real process-flow doc (Emily): the one you said you'd send — does it differ from what I've drawn here?

Sources: Emily's questionnaire "Master Data — What I Need From You" (Parts A–F, role + permission grids); the 2026-06-12 meeting recording (verbatim transcript + flowchart frames); Field Dictionary "Process Steps" tab (Brodie's draft, flagged by Emily as "assume wrong"); docs/local_website_plan.md. The earlier docs/temporal_workflow_design.md is superseded by §0 on the Commercial-Lead point.