Show sender for manual texts and emails in work orders

Objective

• Add clear sender attribution for manual communications on work orders so teams can answer “who sent this?” without log digging.
• Reduce support and client-care risk when an unexpected message is sent by making accountability visible directly in the activity timeline.
• Keep sender attribution behavior consistent across manual text and manual email experiences.

Background

• Product feedback indicates that manual sends currently appear without reliable sender identity in the work-order communication timeline.
• A recent Axium incident involved a text that should not have been sent, and staff could not determine who sent it from the work order view.
• Manual template SMS and normal manual texts were both reported as missing sender visibility.
• The current issue context includes this screenshot from production:

Product Decisions

Locked

1. Attribution requirement — Manual sends must show who initiated the send in the work-order communication timeline.
2. Surface priority — Manual SMS coverage is required, including template-based manual sends and custom/manual text sends.
3. Audit usability — Sender identity must be visible in the UI where staff review communication history, not only in backend logs.

Open (Remaining product clarifying decisions)

1. Display format — Should attribution display full employee name, role + name, or avatar + name in each manual message row?
2. Answer: same display as on notes/manual email sends
3. Email parity scope — Should this work include only one-off/manual template email entries, or also any other staff-initiated email send paths that can appear on the work order timeline?
4. answer: no update needed - email already functions as desired
5. Historical backfill — Should previously sent manual messages remain unattributed, or should a one-time backfill be attempted where sender can be inferred from logs?
6. Answer: Backfill historical if easy to do but not essential.
7. Permission visibility — Is sender attribution visible to all staff roles that can view work-order activity, or restricted by role/permission?
8. Answer: yes
9. External visibility boundary — Confirm whether sender attribution is internal-only and must never appear on any client-facing timeline or portal surface.
10. Answer: internal only.

Scope

Backend

• Manual email sender metadata is already captured in attik-backend/src/routes/emailBuilder.ts (/send-manual) via _sentBy on FlowActionResult.
• Manual SMS template and custom sends in attik-backend/src/routes/smsBuilder.ts create FlowActionResult entries with triggeredBy: 'one-off-sms', but do not currently persist _sentBy.
• Communication enrichment in attik-backend/src/routes/flowActionResults.ts currently resolves _sentBy only for one-off-email; scope includes aligning SMS enrichment if product confirms SMS parity behavior.
• Direct freeform SMS sends in attik-backend/src/routes/twilio.ts (POST /) currently send via Twilio without sender attribution metadata; product decision needed on whether this path should join the same attribution model.

Frontend

• Activity rendering in attik-frontend/src/components/activityFeed/ActionFlowBlock.tsx currently displays sender identity for one-off-email entries using sentByEmployee, while SMS entries do not show equivalent sender attribution.
• Freeform SMS entry from attik-frontend/src/components/textInput/TextingInput.tsx uses the direct twilio route when no template modal path is used, which affects attribution consistency in the timeline.
• Timeline display container behavior in attik-frontend/src/components/activityFeed/ActivityTSWrapper.tsx supports contact name/avatar rendering and is a relevant UI touchpoint for attribution presentation choices.

References

• Slack context: https://attik-talk.slack.com/archives/C0AQFEHRWG6/p1781559150397199
• Backend entry points: attik-backend/src/routes/smsBuilder.ts, attik-backend/src/routes/flowActionResults.ts, attik-backend/src/routes/twilio.ts, attik-backend/src/routes/emailBuilder.ts
• Frontend entry points: attik-frontend/src/components/activityFeed/ActionFlowBlock.tsx, attik-frontend/src/components/textInput/TextingInput.tsx