Role-scoped conditions when contact appears in multiple job roles

Objective

• Support action flow conditions that apply per recipient role when the same contact appears on a workorder in more than one contact role—without treating every flow that uses contact-already-on-job as a single job-wide on/off switch.
• Example: Block email to Listing Agent when the person in that role is also on the job as Buyer Agent—while still allowing that contact to receive their actions sent to other contact roles they occupy (e.g. the Buyer Agent).
• Complement job-wide duplicate detection (contact-already-on-job) with rules teams can target at this role’s assignee vs another role on the same job.

Background

• Today contact-already-on-job is job-wide: evaluation walks the full roster (inspection.people or _conditionScopePeople) and returns true when the same contact identity appears more than once—typically the same person on multiple roles.
• Email/SMS evaluate conditions per recipient (people: [recipient]) but duplicate checks still use the full job via _conditionScopePeople, so contact-already-on-job is_false effectively means “no one on this job is duplicated anywhere”—not “the person in this role isn’t duplicated in that other role.”
• contact-role-ids reflects the current recipient’s role(s), not “does this recipient’s contact also hold role X elsewhere on the job?”
• Product need: intentional multi-role assignments are common; teams want to send or block based on overlap between specific roles, not disable all actions globally when any duplicate exists.
• Related bug (separate issue): ATT-1485 — contact-already-on-job can evaluate incorrectly after role replacement (contact A swapped for distinct contact B on the same role). Fix that without changing the job-wide semantics described here.

Scope

Product / UX

• Decision needed: New condition attribute vs extending contact-already-on-job with scope (job vs recipient vs recipient-and-other-role).
• Decision needed: Whether “other role” is required (Listing Agent + Buyer Agent) or optional (any other role on the job).
• Expose in action flow condition UI (attik-frontend/src/components/conditions/templatingData.ts) with clear copy—e.g. recipient’s contact also assigned to role(s) …
• Document interaction with existing contact-already-on-job so teams know when to use job-wide vs role-scoped rules.

Backend

• Evaluation: attik-backend/src/util/functions/actionFlows/attributePathResolver.ts, conditionsResolver.ts — new or extended resolver using current recipient from people[0] and full roster from _conditionScopePeople / inspection.people.
• Identity: attik-backend/src/util/functions/actionFlows/recipientIdentity.ts — resolveContactIdentity for matching the same person across roles.
• Per-recipient paths: attik-backend/src/util/functions/emailBuilder/renderEmail.ts, attik-backend/src/util/functions/actionFlows/renderSms.ts — already pass _conditionScopePeople; role-scoped attribute should evaluate in that context.
• Existing attribute (unchanged semantics unless product decides otherwise): contact-already-on-job remains job-wide duplicate detection.
• Tests: Add cases for recipient in role R1 who also appears in R2; recipient unique; optional R2 not on job.

Frontend

• Condition builder: templatingData.ts, ValueConditionInput.tsx (if role picker needed, follow contact-role-ids patterns).

Out of scope

• Fixing role-replacement stale people (ATT-1485).
• Job-level tag conditions (e.g. VIP tag on any contact on job)—separate product thread.

References

• ATT-1485 — related bug: wrong evaluation after role replacement
• attik-backend/src/util/functions/actionFlows/attributePathResolver.ts (contact-already-on-job, contact-role-ids)
• attik-backend/src/util/functions/actionFlows/recipientIdentity.ts
• attik-backend/src/util/functions/emailBuilder/renderEmail.ts
• attik-frontend/src/components/conditions/templatingData.ts