Re-use existing email, phone, and address fields in CRM's custom fields

I'm asking the Member Platform team to dive into this during today's Slack meeting.

Taking phone as a simple(r) example, I went down a bit of a rabbit hole.

It's late so I'm going to need to come back to this later, but some quick-ish thoughts...

There are quite a few contrib projects that define their own phone field type. There are some contrib projects that provide validation and/or a formatter for the core telephone field type. I think we should leverage some of the existing functionality provided elsewhere in contrib by A) extending one or more field types, field formatters, and/or field widgets or otherwise ensuring we don't lose out and we don't reinvent the wheel; and/or B) using a field collection or entity (see below) to allow wholesale use of an existing project's field type. Further analysis needed.

https://www.drupal.org/project/telephone_advanced →
https://www.drupal.org/project/telephone_validation →
https://www.drupal.org/project/telephone_formatter →
https://www.drupal.org/project/telephone_plus →
https://www.drupal.org/project/telephone_type →
https://www.drupal.org/project/telephone_international_widget →
https://www.drupal.org/project/phone_international →
https://www.drupal.org/project/phonenumber →

I'm increasingly wary of CRM using a field type that is essentially a bunch of fields related to a phone number, but that are quite a bit more than a phone number. More complex use cases could need to track data (that we aren't currently anticipating) about each phone number such that it would be beneficial for a phone number to be fieldable. We can't change the field schema later ✨ Field type modules cannot maintain their field schema (field type schema change C(R)UD is needed) Needs work . While there are obvious downsides, I think we should discuss using a field collection or defining an entity to capture the various data related to a phone number.

Additional things that might warrant tracking per phone number, whether as a field or a reference from some other entity to a Contact's phone number:

• Confirmation status (similar to confirming an email address)
• Opt-in/out
• Communication preferences
• Activity (e.g. calls or texts to/from)

I'm not suggesting that any of these should be tracked for 1.0 (or even necessarily in a future CRM release). Similarly, I think we should not track mobile carrier in 1.0.

I haven't gone down the rabbit hole for the other field types, but I plan to. I suspect I will come to similar conclusions.

Would it be helpful to split this issue to tackle each of email, address and telephone separately? That way we can reduce the size of the merge request for reviewers and testers. It could mean an eventual merge conflict for update hooks.

So it seems like there are several different aspects to this question, from a CRM perspective:

## What is the contact info?

Different aspects here:

- Validating the phone number - does it fit validation rules for the country? Does it allow for PBX things like extensions, or voice rules to reach a person?
- Identifying the phone number -- home, work, mobile, etc
- Can it accept an SMS? Fax?
- How do we know which number the contact wants to use?
- Is there a place to add a note to help answer these questions?

## What contact method does the person prefer?

There have been several attempts to provide preferred contact methods a user can select. There used to be Message Framework, Notifications, Courier. For D11, I see DANSE → and I see a dev " Notifier → " module leveraging a Symfony system.

Looks like at the moment DANSE is the clear active project in use that provides a framework for this aspect.

@mradcliffe, Yes I think it could make sense to split this issue, but perhaps it would be wise for us to first determine the overall desired approach as there are some analogous needs across the different fields.

@freelock Good considerations. I'm arriving at the conclusion that it might not be realistic for us to determine all the likely needs up front so it would be wise to make phone number related data extensible (i.e. a field collection or entity type rather than a custom field whose columns are immutable).

A quick look at DANSE suggests to me that it isn't set up to handle non-User entities as first-class recipients. However, Notifier → has documentation making clear that it does. I posted a message in the #danse Slack channel to confirm and will report back.

As requested by @bluegeek9 in today's Member Platform meeting 📌 Member Platform (Zoom) Meeting on May 8, 2025 Active , I'm going to prototype a CRM Contact Address entity type (or Storage → Type) with an Address → field, its integration with CRM Contact via Inline Entity Form, and plotting contacts' addresses on a map to illustrate the value of using the contrib address field.

Should also consider if/how SimpleNews might fit into this...

Yes, good idea.

jurgenhaas, DANSE maintainer and Member Platform supporter, replied:

that's correct, DANSE currently is built to users as recipients. Thinking about it, extending that to entities as recipient in general, shouldn't be hard. So, if DANSE otherwise is appealing, I'd be willing to make that enhancement.

We should probably move this discussion into a different issue.

bluegeek9 → changed the visibility of the branch 3522243-reuse-fields to hidden.

Please see comments in the MR

Issue fork branch 3522243-map-demo (untested) contains the config I used to spin up a quick proof of concept of mapping Contacts' addresses. Here's a screenshot of that in action:

I am working on using the crm_contact_detail for address/email/telephone and retaining the ability to select a primary.

https://www.drupal.org/project/primary_entity_reference →

It still needs to work with the Inline Entity Form, and other widgets and formatters.

I look forward to reviewing! Will Views, ECA, Search API, Token, etc. be able to navigate the reference as they do vanilla Entity Reference or will they (each?) require additional integration work?

So far I haven't been able to find any evidence supporting your concern about simply treating the first referenced entity (delta 0) as the primary, but I'm seeking feedback from others.

I will need to check various integrations to tell for sure. I imagine it will work out of the box for some and some will need integration.

Inheritance has made everything very easy so far.

Renaming this to focus on Address. Will create and link to follow up issues for Phone, Email, and other needs. Will be most helpful to get this MR merged to facilitate the follow-ups.

Does a use need the 'administer crm contact detail types' to create an address?

Added follow-up issues to IS.

Does a user need the 'administer crm contact detail types' to create an address?

Sorry I missed your question earlier!

Honestly I have not focused on permissions yet. I think the ability to create/edit/delete an Address/Phone/Email should be inherited from the ability to create/edit the Contact and it should only be possible in the UI via inline Entity Form. I created 📌 Address/Phone/Email CRUD access control Active to follow-up.

Automatically closed - issue fixed for 2 weeks with no activity.