Creating a Salesforce contact should not automatically turn a conversation into a sales task.
That is a design position, not a statement about a mandatory Salesforce default. If your organization creates tasks whenever a Contact is saved, someone configured that behavior. The entry rule can be reconsidered.
In a personal post, I wrote: “Human relationships do not work like a CRM.” This is a translation from my Spanish original. The technical question it raises is narrow: what event should authorize an internal follow-up task?
This article proposes a hypothetical design. It has not been executed or validated in a Salesforce organization as part of this draft. There are no deployment results or customer outcomes to report.
Define the event before the field
For this example, the event is an explicit request for commercial follow-up. Merely meeting someone does not satisfy it. The team needs an agreed way to record the request rather than infer it from a pleasant conversation.
The proposed custom field on Contact is a checkbox named Solicita_seguimiento_comercial__c. In English, the name means “requests commercial follow-up.” It is not a standard Salesforce field. Its initial value is false.
This checkbox does not represent legal consent for marketing. A request for a proposal should not silently become permission for unrelated messages. Record only information needed for the commercial purpose, without adding personal details that the process does not need.
A checkbox is intentionally limited. It represents a current state, not a history of requests. If the process needs to distinguish separate requests over time, consider a model that records them individually before building this version.
Configure the proposed record-triggered Flow
Work in a sandbox. Create the custom field using your organization's administration conventions and review field access. People who record requests need an interface that makes the meaning clear. The checkbox should not be preselected as a shortcut for contact creation.
The variant described here uses Contact creation or update as the trigger. That allows a request to be recorded during initial entry or later. If your business process only accepts requests after creation, narrow that scope and adjust the tests.
The proposed setup is:
Object: Contact
Trigger: created or updated
Entry condition:
Solicita_seguimiento_comercial__c Equals True
For updated records:
Only when a record is updated to meet the condition requirements
Run after save, optimized for actions and related records
This block describes configuration; it is not deployable metadata. Interface labels may vary with the language of your environment.
The update option matters. Running whenever the checkbox is true could create a task on unrelated edits. Running when the record moves into the qualifying state targets the transition instead. For creation, a record initially saved with the checkbox true also qualifies in this version.
The Flow runs after save because it creates another record. Salesforce's record management material for Flow explains operations on records. This example does not use a before-save update to change the triggering Contact.
Create the internal Task
Add a Create Records element for Task. Associate it with the triggering Contact through WhoId, using the Contact identifier available as $Record.Id.
Choose the task subject to describe the actual request. Decide who should own the task according to your organization's assignment process. Do not paste user identifiers from another environment. Select status values that exist in your organization rather than assuming every environment uses the same configuration.
Review required fields and validation rules before testing. The sketch above does not account for every organization-specific constraint. Decide how a creation failure will become visible to the responsible team without exposing unnecessary contact information.
This design does not send email. An internal task and an outbound message are separate actions. The task should not be treated as permission to enroll someone in a marketing sequence.
Before activation, inspect existing Contact automation. Another process may already create follow-up tasks. A carefully scoped new Flow does not prevent a different automation from acting on the same record.
Test the absence of a task
Start with a Contact whose checkbox is false. The expected outcome is no Task from this Flow. Update another field without changing the checkbox. Again, this Flow should not create a task.
These are expected outcomes, not results observed during preparation of this article. Confirm them in your sandbox, including whether other automation produces a task independently.
Next, record a hypothetical follow-up request by changing the checkbox from false to true. The expected outcome is a Task associated with the correct Contact and assigned according to the rule you chose.
Update an unrelated field while the checkbox stays true. The expected outcome is no second Task from this Flow. This test checks whether the entry configuration actually represents a transition rather than a continuously true condition.
Also test creation with the checkbox already true. In the creation-or-update variant, the expected outcome is a task. If that should not happen in your process, the proposed scope is wrong for your requirement.
Repeated requests are a separate requirement
Set the checkbox back to false and then to true again. The basic design can produce another task because the record re-enters the qualifying state.
That may be appropriate for a new request. It may be wrong if an earlier task is still open. Make that decision explicit. A separate duplicate check or a request-based data model may be needed. This checkbox alone does not provide global idempotency across other automations.
Salesforce Architects' record-triggered automation guide provides context for evaluating entry conditions and record changes. It does not validate this hypothetical Flow for your organization.
Salesforce also describes a Lead as a potential prospect in its Trailhead lead material. That distinction does not decide whether a Contact has asked for follow-up. The request still needs its own representation.
The technical acceptance condition here is deliberately modest: when no request was recorded, this Flow leaves the conversation without a sales task.
Top comments (0)