Expand Phones data type to allow a phone type and extension

[Richard-West]

Phone data type object

Current behavior

The phone data type currently stores:

+---------------------------------------+--------------+
|               Sub-field               |   Example    |
+---------------------------------------+--------------+
| `Phones / Primary Phone Number`       | `4159095555` |
| `Phones / Primary Phone Country Code` | `US`         |
| `Phones / Primary Phone Calling Code` | `+1`         |
+---------------------------------------+--------------+

Requested change

Allow a user to enter a phone type (Work, Home, Mobile, Fax, Other) as well as an extension if necessary.

Example:

+---------------------------------------+--------------+
|               Sub-field               |   Example    |
+---------------------------------------+--------------+
| `Phones / Primary Phone Number`       | `4159095555` |
| `Phones / Primary Phone Country Code` | `US`         |
| `Phones / Primary Phone Calling Code` | `+1`         |
| `Phones / Type`                       | `Work`       |
| `Phones / Extension`                  | `1234`       |
+---------------------------------------+--------------+

[Bredo]

Wouldn't it be more appropriate to simply store it as E.164 always (+ optionally extension)?

[Richard-West]

Wouldn't it be more appropriate to simply store it as E.164 always (+ optionally extension)?

It would be better to store the extension separately, as phone numbers are often exchanged with other systems that may not handle the extension when it is written directly in the number.

Also, I tried to store the extension in the current Twenty build, but I cannot add more than 10 digits for a +1 U.S.-based number. Having the extension stored separately would also make it possible to format the click-to-call number so that we could add a default number of commas for a dialing delay and have the extension dialed automatically.

The link could look something like this: tel:+15551234567,,,987
where at a config level the number of commas inserted could be set by the admin for the given phone system a company is using.

[timothyportnoff]

Rather than a separate extension box, we could let the phone field itself carry DTMF strings:

|               Sub-field               |   Example        |
+---------------------------------------+------------------+
| `Phones / Primary Phone Number`       | `5597774444,,102` |
| `Phones / Primary Phone Country Code` | `US`             |
| `Phones / Primary Phone Calling Code` | `+1`             |
| `Phones / Type`                       | `Work`           |
+---------------------------------------+------------------+

Two Changes to make this work:

1. Increase character limit
2. Allow , and ;,

This way, users could compose any DTMF string they want to navigate any IVR. This is actually how our current phone data is already formatted (From SalesForce, not sure about other CRM's) - and if they are formatted to RFC 3966, that would make moving to or from Twenty handcuff-free. https://datatracker.ietf.org/doc/html/rfc3966

[Bredo]

@timothyportnoff this implementation makes sense to me from a design perspective! Not sure if, for validation and consistency purposes, DTMF should be its own field though 🤔

[Richard-West]

I think that, for maximum compatibility, extensions and DTMF strings should be stored separately. This allows the cleanest data to be stored in discrete fields. If an application needs this data concatenated, it is a simple operation to join multiple fields. However, if all data is stored in a single field, parsing that data requires more effort.

This approach also allows the phone number and extension to be displayed cleanly in the web app as a well-formatted phone number with a separate extension. Storing everything in a single field would require the user to look at something like 12025551212,,,9876 as a phone number, which is not ideal. It would also require additional end-user training to explain how to enter this information.

With an E.164 phone number field and a separate extension field, the user experience becomes much more controlled, and it is more obvious what is allowed and expected in each field.