Skip to main content

Contact with Unsubscribed Status stuck in Automation

When a contact requests to unsubscribe from emails, the automation is automatically canceled for that contact, and they don’t continue with the next steps in the automation. That means the contact’s status shows as “cancelled,” which leaves them stuck in the automation.

However, I need the contact to remain in the automation and continue to the subsequent actions, even if they’re not receiving emails.

I need the contact to move through all steps of the automation because I have processes related to tags and internal controls.

How can I ensure that the contact remains in the automation and executes the next actions? Even if the contact is in the unsubscribed status.

Is there a trick or a code snippet that I can modify to change this behavior?

I really need this, I have over 2.7 million contacts.

I'm already in contact with support via chat on the website, however, it's the weekend.

Thank you.

Jose Luis Duron

I think you have to reimagine your flow/funnel.

If someone unsubscribes from your list, NOTHING else will go for him/her from the "unsubscription".

Eduardo Sachs

Jose Luis Duron Hello José, thank you for your comment, but I would like to explain more clearly why this functionality is crucial for my use case in FluentCRM: even if a contact opts out of receiving emails, we still need to run internal processes related to that contact, including updating tags, moving them between lists, and triggering other workflows not related to email. Keeping the contact in the automation, even after unsubscribing, allows us to have a complete view of their history and customer journey, which is essential for future analyses and for a better understanding of our contacts’ behavior.

In addition, it allows us to create more precise segmentations, execute specific actions based on past behaviors, ensure compliance with data protection regulations, and gives us more flexibility to manage our CRM processes according to our specific needs. It is important to emphasize that we are dealing with a massive database of over 2.7 million contacts. At this scale, efficient management of each contact is crucial. Every automation, tag, or status change has a significant impact on our processes and data integrity. Maintaining consistent and continuous automations, even for contacts who have unsubscribed from emails, is fundamental to keeping our database organized, up to date, and useful for our internal operations. Any small optimization or added flexibility in managing these automations can have a huge impact on the efficiency of our operations, given the volume of contacts we manage.

Furthermore, it is crucial to consider that many contacts who unsubscribe eventually return to our active database. This can happen for various reasons: changes in their interests, new needs that arise, or simply because they’ve once again found value in our content. Keeping these contacts in automations, even when inactive, allows us to resume the customer journey more efficiently when they decide to re-engage. This continuity of the customer journey, even during periods of inactivity, is essential to provide a personalized and relevant experience when the contact returns—something that would be much more difficult if the history and progress in the automations were completely lost.

I understand that the default behavior is to stop all actions after someone unsubscribes, but for many businesses, including mine, the ability to continue certain internal processes is vital. This does not mean sending emails to contacts who have unsubscribed; rather, it means preserving the ability to effectively manage those contacts internally. I hope this clarifies why this functionality would be so valuable for FluentCRM users like me, especially given the scale of our database and the cyclical nature of customer journeys.

Jose Luis Duron

Eduardo Sachs I understand what you want to achieve. BUT FCRM doesn't allow you (for now) what you need/want.

If a user is on many lists, but he unsubscribes, he is unsubscribed from ANY thing.

At the actual stage you can't achieve your ideal scenario.

P.S. Sincerely, I think it will not change (soon neither later).

Eduardo Sachs

Jose Luis Duron In my case, it's fine if the contact unsubscribes from just one list, and if they are in other lists, they should also be unsubscribed. However, the contact needs to continue with the pre-defined actions in the automation they are currently in. Is it possible to have a snippet to make this small adjustment, you know?

Eduardo Sachs

Jose Luis Duron Imagine you have 10 contacts who are marked as unsubscribed. If you add these unsubscribed contacts to your automation, they will still proceed through all the steps and actions within that automation. However, whenever an email step appears, those emails will not be sent, because the contacts are unsubscribed and therefore cannot receive any emails.

Even though the emails aren’t delivered, the contacts will continue moving from one step to the next in the automation, executing all non-email actions (for example, adding a tag, or being added to a list). Even if the contact has the unsubscribed status.

This works if a contact starts out as unsubscribed before entering the automation. However, if a contact is in an automation and unsubscribes partway through, the automation stops working for that specific contact, meaning no further actions will apply to them.

In summary:

Unsubscribed from the start: They go through the automation but receive no emails.

Unsubscribed during the workflow: The automation halts for them as soon as they unsubscribe.

That doesn't make much sense, you know?

Eduardo Sachs is this not exactly what you need?

Eduardo Sachs

Natascha Vantuykom When a contact is in automation, and its status changes to unsubscribe, the contact remains stuck in the automation without proceeding to the next steps. Even if this option is checked. However, FluentCRM support has already provided me with a fix, which is a snippet and a modified PHP to make this snippet work.