When the customer gives consent to a company to send text messages to them, recording that action seems like a simple task. The business could just label the customer as being “Opted In” in Salesforce; however — as the Salesforce SMS conversation increases – that simple status may not be enough.
A business may later need to know when the customer gave permission — which phone number it applies to, where the consent came from, or whether the customer changed that preference. Without those details, it can become difficult to verify how a customer opted in — especially when the business needs to prove a clear record of consent.
So, what should businesses really store when dealing with SMS consents within Salesforce?
This article breaks down the SMS consent data model Salesforce supports, including the objects, fields, consent records, and audit trails — which businesses can use to keep consent information organized, traceable, and easier to verify over time.
What Is an SMS Consent Data Model in Salesforce?
The SMS consent data model defines the way a company stores customer consent for receiving SMS messages in Salesforce.
Apart from the simple opt-in/opt-out checkbox, the model will associate the user with other data such as the user’s mobile number, status of consent, type of consent, and date of consent. Additionally — the model could also track any changes to the customer’s consent.
The goal is quite simple: who gave the consent, the type of consent given, when it was given, and how it was modified.
What type of model is right depends upon the details of the business. For an easy opt-in data model Salesforce implementation, just a few fields might be required, whereas a more complex company would need consent-related records and a detailed history of changes.
Salesforce SMS Consent Data Model: Objects and Relationships
After laying out the fundamental model, the following step is choosing where each component of the consent record will be placed in Salesforce. This is where the object relationships come in useful.
An example of the Salesforce consent record structure could include:
| Salesforce data element | Corresponding role in the consent model |
|---|---|
| Contact / Individual | Indicates individual who corresponds to the consent |
| Contact Point Phone | Indicates corresponding phone number |
| Contact Point Consent | Connects the consent to this contact point |
| Communication Subscription | Describes the kind of communication/subscription |
| Communication Subscription Consent | Indicates the consent of the customer for this subscription |
The specific format will depend upon the version of Salesforce that you are using, but the most important thing is ensuring that the consent record remains associated with the person, contact point, and purpose of communication.
This object-level structure provides businesses with a good basis for consent object design instead of having one “SMS Opted In” field.
Read more about managing SMS preferences in our article about Salesforce SMS opt-in, opt-out, and compliance.
Which Fields Should an SMS Consent Record Include?
The text message consent record should be detailed enough to show who has given their consent, on what phone number they have done so, and under what conditions and when.
One can suggest a very simple consent data model in Salesforce — which consists of only some basic fields, but other messaging systems can require more details about the consent.
| Field | Details in the Field |
|---|---|
| Consent Status | Consent Opt-In / Opt-Out |
| Phone Number / Contact Point | The phone number on which the consent was given |
| Date/Time of Consent | Date and time of giving/updating consent |
| Consent Source | Source of the consent |
| Consent Mode | Method of giving consent |
| Purpose of Communication | Nature of SMS marketing messages allowed |
| Date/Time of Withdrawal | Date and time at which the customer withdrew consent |
| Consent Content | Details in the consent |
It is up to the business entity to decide what the exact fields would be depending on the process of obtaining and managing the consent. What is important is to gather enough details for any interpretation of the record regardless of its state.
SMS Consent Status vs Consent History: Why Both Matter
The consent model should be able to answer two separate questions:
- What is the customer's consent status now?
- What happened to that consent over time?
These are related, but they serve different purposes.
| Current consent status | Consent history |
|---|---|
| Current opt-in or opt-out state | Previous consent decisions |
| Phone number/contact point it applies to | Date and time of each change |
| Current communication subscription or purpose | Source or method of the consent event |
| Current consent record | Details of the change, where captured |
For instance, when a user subscribes to SMS marketing and then texts STOP, the present status would be Opted Out. However — the history will reveal that the user was previously subscribed at one time in the past.
This will ensure that the two systems are kept separate for businesses to track SMS opt-in status in CRM — without wiping out the information about their past status.
How to Track SMS Consent in CRM without Forgetting History
To track SMS consent in CRM, firms need a system that will help in updating the existing preference, but on the other hand, will also capture the history of how it changed along the way.
This approach should allow for:
- Recording the consent in case the client granted it, changed his/her decision, or cancelled the consent.
- Matching the consent with the right person and his/her phone number.
- Update the status of the consent in case it was changed by the customer.
- Recording the change with its date, origin, and method of occurrence.
- Saving previous records of the consent without overwriting them.
There might be different ways to do that in various Salesforce instances. The thing to remember is the link between the current consent status and its records.
Building an Audit Trail for SMS Consent in Salesforce
The audit log needs to show what was changed, when it was changed, and to which record. In the case of SMS consent — it is necessary to retain the information on each consent event instead of depending solely on the current status of the client.
At the very least, it must enable us to track the following:
- Customer and phone number associated with the consent
- Consent action or status recorded
- Date and time of the event
- Source or method used to capture the consent
- Communication purpose the consent applied to
- Previous and updated values when the preference changes
This leaves a trail of the consent history. Instead of just establishing whether the consumer is opted in or not, the business could also determine how this happened and how the status has changed since then.
Conclusion
A good Salesforce SMS consent data model goes beyond saving an “Opted In” status. The model should connect customer, phone number, consent reason, status, and history into a coherent framework that will stand firm as the customer’s preferences evolve.
Properly defined objects, fields, consent entries, and audit trail will enable businesses to retain an accurate record of SMS consent and the information required to prove that record later.
The point here is straightforward: do not just save the status of the consent. Save the context of it.
