## The two moments when Treble writes This is the distinction almost every limitation comes from. | Moment | What happens | What controls it | | - | - | - | | **Creation** | Treble doesn't find the person's record and creates it | The required fields Treble detects automatically, plus the advanced rules on this page | | **Update** | The record already exists and Treble writes a field | The blocks in your flow | The blocks you configure in the conversation builder work in the **second** moment. Each block writes a field **after** the record exists. That works perfectly as long as Salesforce allows that field to be written afterward. It stops working when Salesforce requires something **on creation**. The two cases that come up most: * **A validation rule** that requires a value in order to create the record (for example, a data processing authorization). * **The record type**, particularly with [Person Accounts](/en/docs/integrations/salesforce/features/person-accounts): an account can't be converted into a Person Account after it's created. In those cases, the flow block arrives too late by design.

## Creation rules For those cases, Treble can apply **rules that run at the moment the record is created**, configured per object within your integration. The key property: a creation rule **always** applies when the record is created, regardless of whether Salesforce reports that field as required or not. That's why it solves what a block can't reach. ### What you can do The most common: *"every record this integration creates must have X in this field"*. It works for record types, yes/no flags, lead source, default country, internal classifications, and in general any required field in your model that doesn't depend on the conversation. It's also the fastest change to apply. Treble knows the contact and can derive values from it: the WhatsApp profile name, the phone number in different formats, the email if it has one, or a generated email when it doesn't. It's the usual way to fill in required name or email fields on objects that require them. When you need your own transformation —trimming a document to a certain number of digits, translating a value into your internal nomenclature, composing a field from several pieces of data— a specific rule can be written for your account. It's not an exceptional case, but it **requires development on Treble's side**: it's requested, coded and deployed. It's also possible for a rule to use what the person answered during the conversation and include it when the record is created. It's the way to go when you need, for example, the record type to depend on what the person chose in the chat **and** for that to be set from the moment of creation. Like the previous case, it requires development.

## The limits worth knowing There are three, and it's worth being clear on them before designing something around this tool. A rule on the `Account` record type affects **all** the accounts the integration creates, in **all** flows. Today you can't have "campaign A creates with one record type and campaign B with another" using creation rules. This is the most important limitation. If that's exactly your case, let your Customer Success Manager know: it's one of the things we're working on, and it helps to know how many customers need it. A creation rule doesn't run when the record already exists. To update an existing record, you use the flow blocks, as always. These rules live in the integration's configuration and are applied by the Treble team. They can't be edited from the platform. A change is usually quick —minutes, with no deployment, when it's a fixed value— but it goes through us.

## Other things configured at this level It's the field Treble uses to look up the person and, at the same time, where it writes the number when it creates the record. Today it's **a single field for both things**. If you change the field so the number is saved somewhere else, Treble stops finding the records that have the number in the previous field and starts creating duplicates. If you need to look up by one field and write to another, talk to your Customer Success Manager before changing anything. Defines whether the conversation history is saved as a `Task` or as an `Event`.

Conversation history

Which objects the integration uses, and for each one its phone, name and owner field. It's defined during installation, and changing it afterward means reinstalling.

## Two frequently asked cases By default, Treble writes the number in full international format, with the country code. It's very common to want something else: without the country code, with parentheses and spaces, or split into two fields. That's solved with a **creation rule** on the phone field. If the format you need is a simple transformation of the number, it's a quick change; if it depends on rules specific to your operation, it falls into the custom logic category. Watch out for a side effect: the integration's phone field is the same one Treble uses to **look up** the person. If you change the format of what's written, make sure the lookup still finds existing records, or you'll start creating duplicates. When Treble creates the record, the name comes from the person's **WhatsApp profile**. But that name doesn't always exist and isn't always useful: there are users without a profile name, and there are profiles with emojis or promotional text. You can define with a creation rule what gets written in that case: a fixed fallback value, the phone number, or a combination. That's exactly what several customers do so that no record is left without a name and so that records created by Treble are identifiable. If what you see is the **text of a message** in the name field, that's not the creation: it's an action block writing the person's reply to the wrong field. Check [the action block](/en/docs/integrations/salesforce/blocks/crm-action).

## How to request a change To make it quick, write to your Customer Success Manager with this information: For example `Account`, `Lead`, or the API name of your custom object. The exact **API name**, not the label you see on screen. For example `CC_Autorizacion__c`, not "Data authorization". If it's a fixed value, which one. If it's a record type, the **18-character Id**, which you'll find in *Setup → Object Manager → your object → Record Types*, in the type's URL. Usually: "there's a validation rule that requires this field on creation", or the exact error message Salesforce returns. That saves an entire round of questions.

## Next steps The most common case of a field that must be filled in on creation. When an account represents a person rather than a company. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.