Workflow Create Record cannot fully populate Phone field (country selector not mappable)

[AzimKrishna]

Summary

After the fix in #12343 (E.164 phone handling with "No country"), phone numbers can now be written correctly via the API.
However, the same is not possible via Workflows, because the Phone field’s country selector is not mappable from workflow variables.

This creates a functional gap between API usage and Workflow automation for international phone numbers.

---

Environment

• Deployment: Self-hosted (official Docker image)
• Twenty version: latest Docker image
• Feature used: Workflows → Trigger: Webhook → Action: Create Record
• Field type: Phone
• Phone field config: Default country = "No country"

---

Steps to reproduce

1. Create a Phone field on an object (e.g. Opportunities or Parents)
   • Set default country to No country
2. Create a Workflow:
   • Trigger: Webhook
   • Action: Create Record
3. Send a webhook payload with an E.164 phone number, e.g. "+919999999999"
4. Map this payload value to the Phone field in the workflow

---

Actual behavior

• The phone number is stored as the national number only (e.g. 9999999999)
• The country selector remains unset / default
• The E.164 calling code (+91) is silently dropped

---

Expected behavior

One of the following should be possible:

• Workflow Create Record accepts full E.164 values and preserves them when default country is "No country"
  or
• Workflow mapping exposes the Phone field’s country selector as a writable/mappable input

This is especially important for international lead ingestion.

---

Why this matters

• Updating phone numbers using the API adds a "+1" in front of numbers despite having selected "no country" in the data model #12343 fixed E.164 handling at the API level, but workflows still cannot achieve parity
• This forces users to abandon the Phone field type and use Text fields for WhatsApp / phone numbers
• It breaks international automation use cases and makes Workflows less capable than direct API usage

---

Workaround (current)

• Use a Text field to store WhatsApp / phone numbers in E.164 format
• Avoid the Phone field entirely for workflow-driven ingestion

This works but loses the benefits of the Phone field type.

---

Related issue

• Updating phone numbers using the API adds a "+1" in front of numbers despite having selected "no country" in the data model #12343 – Updating phone numbers via API adds incorrect country prefix when "No country" is selected

---

Happy to help test or provide additional details if needed.

[Ayuussshhh]

Hi @AzimKrishna I saw the issue and i would like to say if you can provide me the logs for more detail from the console and also go to the network tab and see which page and api is failing, or what payload and response we are getting.
After confirming this please share the screenshot so that I can work on it.

[AzimKrishna]

Hi @Ayuussshhh , thanks for the offer.

To clarify, logs and network traces aren't relevant here because this isn't a runtime error. It's a frontend design limitation, the Country Code component simply does not support variable mapping.

I've identified this type limitation in my recent PR #17194, and identified what I believe is the root cause. Please check that in detail.

Please verify the reproduction steps locally and you'll see the issue immediately.

[AzimKrishna]

Hi @FelixMalfait,

I saw that PR #17194 was rejected, and I completely understand the concern about the "strange type conversions" and the need for a cleaner implementation.

I wanted to reach out because I encountered this limitation while using Twenty for my own business, generating records via workflows where the country code comes from a variable. Since this is a blocker for my use case, I’m keen to contribute a proper fix.

The Goal:
I want to enable the FormCountryCodeSelectInput to accept a Variable Picker, allowing the frontend to map a variable to the country code field. The backend would then receive this variable string and use it to infer the correct country calling code during execution.

I noticed that in issue #12343, we improved the API to smarter infer country codes from phone strings. The API essentially offers more flexibility than the Workflow UI here. My goal is to bridge this gap, allowing the UI to accept a variable string for the country code, just like the API handles inference.

Rationale from my rejected PR:
My previous attempt modified the frontend components to enable variable picking but did not update the core types (like AdditionalPhoneMetadata), leading to the need for manual type casts (the "strange type conversions" you noted) to bypass the strict CountryCode requirement.

My Question:
What is the correct architectural pattern to support this?

1. Should we officially allow "resolvable" strings in the CountryCode type definition?
2. Or should the frontend/workflow engine handle this without changing the shared types, perhaps by resolving the variable before validation?
3. Is there a preferred way to bypass isValidCountryCode specifically when a variable syntax is detected?

I’m eager to contribute a proper fix that aligns with your vision. Any pointer on the right direction would be appreciated!