Problem/Motivation
The current CRM custom entities (Contacts, Relationships, and Contact Methods) are revisionable but do not support the Core Workspaces module. In a high-integrity CRM environment, performing large-scale data migrations or deduplication/merging of contacts directly on the "Live" site is high-risk. There is currently no way to stage these destructive or complex data changes in an isolated environment for review before they affect production data.
Steps to reproduce
- Enable the Workspaces and Workspaces UI modules.
- Switch to a non-live workspace (e.g., "Stage").
- Create or edit a custom CRM entity (Contact).
- Observe that the change is applied globally (or not tracked by the workspace) because the entity storage is not workspace-aware and the entity lacks the
EntityPublishedInterfacerequired for standard validation.
Proposed resolution
Integrate the CRM entities with the Workspaces module to allow for "Draft" migrations and "Staged" deduplication.
- Update
@ContentEntityTypeannotations to includerevision_metadata_keysand ensure thestatuskey is explicitly defined. - Implement
EntityPublishedInterfaceon the affected entity classes. This will act as a bridge, mappingisPublished()andsetPublished()to the existingstatusboolean field. - Ensure the entity storage handler properly supports
WorkspaceResettableInterfacefor clean deployment transitions.
Remaining tasks
- Update entity class definitions and annotations.
- Generate and run database updates for required revision metadata fields.
- Create a
WorkspaceValidatorif specific business logic is required to prevent "Dead" contacts from being pushed to Live. - Manual testing: Perform a contact merge in a workspace and verify that the deletion of the duplicate and the update of the survivor are atomic upon "Push to Live."
User interface changes
CRM entities will now appear in the Workspaces "Manage" and "Deploy" dashboards. Users will be able to see a list of pending contact/relationship changes before pushing them to the live site. No changes to the primary CRM entity forms are expected.
API changes
Data model changes
The workspace_association table will now track revisions for contact, relationship, and contact_method entity types. No major schema changes are required for existing fields, as the entities are already revisionable.
Comments
Comment #2
bluegeek9 commentedComment #3
jdleonardI could imagine sites that don't want CRM content entity changes to be tracked in this manner. For example, the site might use Workspaces for page content, but expect their CRM to function "normally" and not get tied up with page content changes. Would this plan support this option?
Comment #4
bluegeek9 commentedI think site builders will want the ability to import contacts in a sandbox. I think it can also be used for merging contacts in a sandbox.
I am not familiar enough with Workspaces to answer your question.