>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3618703. --> Reported by: [bluegeek9](https://www.drupal.org/user/1286304) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>ECA has emerged as the front runner of automation in the Drupal ecosystem.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Integration with ECA. Provider Events and Actions.</p> <p>crm_eca should be a CRM contrib submodule (eca + crm). It exposes CRM&rsquo;s own services and constraints to ECA.</p> <p>eca_content already covers generic insert/update/delete/load/set-field on crm_contact, crm_contact_method, crm_relationship, and crm_user_contact_mapping. Do not reimplement those. Wrap what generic entity actions get wrong: mapping uniqueness, person-only users, nested methods, relationship type rules, email lookup.</p> <p>Events<br> Content-entity CRUD is already in eca_content (content_entity:insert on crm_contact / crm_relationship, etc.). Add events only where CRM dispatches its own Symfony events or the timing differs from entity save.</p> <p>Event Why it is not eca_content<br> User&ndash;contact mapping requested<br> crm_user_contact_mapping_event runs in ensureContactForUser() on an unsaved mapping, before lookup/create. Entity insert fires too late.<br> User mapped / unmapped<br> After map() succeeds or a mapping is deleted. Lets models run without listening to a storage entity most site builders never see.<br> Optional later: contact method added/removed as primary, relationship became inactive (end_date). Skip those until someone needs them.</p> <p>Conditions<br> Condition Uses<br> User has a mapped person<br> getContactIdFromUserId()<br> Contact is mapped to a user<br> reverse lookup<br> Contact bundle is person / organization / household<br> mapping and name rules<br> Contacts are related (type, optional active-only)<br> employee, member, household_member, &hellip;<br> Email (or phone) already exists as a contact method<br> same as lookup_contact<br> Negate-friendly, token inputs for user/contact/email.</p> <p>Actions (this is the module)<br> These are the CRM APIs ECA cannot call today.</p> <p>User mapping (crm.user_contact_mapping)</p> <p>Load mapped contact &mdash; user token in, contact token out (NULL if none).<br> Load mapped user &mdash; reverse.<br> Map user to contact &mdash; map($user, $contact). Fail clearly if a mapping exists or the contact is not a person.<br> Ensure contact for user &mdash; ensureContactForUser(): reuse mapping, or run CRM&rsquo;s lookup/create according to lookup_contact / auto_create_user_contact_mapping. This is the action the Woo model would use instead of inventing CRM rules.<br> Unmap &mdash; delete the mapping entity; do not delete the contact unless the model does that separately.<br> Contact methods</p> <p>Generic &ldquo;create entity + set reference&rdquo; is brittle: methods need bundle (email / telephone / address), detail (main, billing, home, work), and attachment on emails / telephones / addresses (primary-entity-reference, often inline).</p> <p>Add email / telephone / address to contact &mdash; create method, set detail, append to the right field, save contact. Tokens for values (Address field as structured bits, not one string).<br> Find contact by email &mdash; CRM&rsquo;s lookup (exactly one person, or fail/empty). Needed when auto-map on user insert is off, as on this site.<br> Relationships</p> <p>Create relationship &mdash; type, contact A, contact B, optional start/end. Enforce asymmetric types (employee: person &harr; organization), bundle checks, and limit_* from the type config. eca_new_entity will not do that validation for you.<br> Do not add &ldquo;create person from first/last name&rdquo; as a special snowflake if eca_content can set full_name.given / full_name.family. Add a thin set person name from given/family action only if the Name field is too awkward in the modeller.</p> <p>Tokens<br> When a CRM event/action runs, set:</p> <p>[crm_contact] (and id, bundle, label)<br> [crm_mapped_user] when a mapping exists<br> [crm_relationship] after create<br> [crm_contact_method] after add-method<br> Primary email/phone as read-only tokens are useful; don&rsquo;t rebuild the Name module.</p> <p>Config and access<br> Actions take entity tokens and config entity ids (relationship type, method detail), not hard-coded person except as a default.<br> Run as the same user ECA already uses; respect CRM permissions (create crm_contact, mapping admin, etc.) or document that models must switch user.<br> map() throws if a mapping exists &mdash; surface that as a failed action (so Woo can 500/retry), not a silent skip.</p> <p>Minimum viable crm_eca<br> Ship this first; it is enough for webhook-driven provision and for other sites:</p> <p>Event: mapping requested (crm_user_contact_mapping_event)<br> Conditions: user has mapped contact; contact is person<br> Actions: load mapped contact; map user to contact; ensure contact for user; add email; add telephone; add address; find contact by email<br> Action: create relationship (type + A + B)<br> That is the whole product: ECA wrappers around UserContactMappingService, contact-method attachment, and relationship rules. Everything else is already eca_content / eca_user / group_action.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <h3 id="summary-data-model-changes">Data model changes</h3>