We've been using Salesforce to send out Email campaigns for a good numbers of years now. When we first started using it, we were using it as the platform intended it, which is, using the publication lists to segment and to associate Data Extensions in an User-initiated Email send to send out campaigns and managing Subscribers' marketing preferences within the platform. However, along the way(before I even joined the company), we have moved the preferences management outside of the platform via an "unsub" link to an external site.

As a result of this, there may be some subscribers' information that get "stuck" within the platform and may never be informed of the updates/changes that may be happening in the external platform so if a subscriber has unsubscribed from the global list before but have since opt-in from the external site means that Salesforce will never send emails to that subscriber. You can assume that the external platform becomes the one central location that manages the subscribers' information and the data extensions that we receive when it gets imported into Salesforce are "washed" based on those information.

Now, I'm looking an overall solution to manage this and if anyone has experience in this can advise on what I should do but otherwise I have a slight idea of what I can do and maybe me asking specific questions might help, so here goes:

  1. It sounds like the first thing I need to do is to start fresh, deleting all subscribers and receive new data extensions since all new data extensions would presumably be current/recent. This should eliminate the subscribers' data inconsistency.
  2. Treat all email sends as "Transactional Emails" set in Send classifications, even for Marketing/Commercial emails so as to ensure no one can unsub from the platform.

Please discuss, advise or recommend.

Thanks, Elvin

1 Answer 1


Before you go down this road, how many opted-out subscribers are actually trying to re-subscribe?

To answer the question more directly, you can update subscribers' comms preferences within SFMC via APIs (you can find these in the Knowledebase) to give you the feedback loop you require. We use this method for email & SMS, where email unsubscribes & SMS STOPs are captured in SFMC, extracted via FTP to our core platform on a daily basis, preferences are updated on the customer-facing site, and any subsequent updates made by the subscriber or customer care team are returned into SFMC via API to close the loop.

Deleting all subscribers shouldn't be done lightly, although this depends on how you use the platform and what historical data you're interested in keeping.

Similarly, sending via Transactional Emails for all sends can cause issues around SPAM compliance etc if your subscription management process isn't rock solid.

  • Honestly speaking, I'm not sure how many, we work with a few stakeholders so, sometimes, it's hard to see the overall picture. I'm also keen to use as little resources as possible, I'm not sure how much work is required to do it via API and also I have to point out I have little or no experience when it comes to that. I'm keen to find out more if you can direct me. Thanks for pointing out the risks. What is your thoughts about what I proposed though, will it solve the problem, you think?
    – Elvin
    Commented Jun 17, 2019 at 1:31
  • I'd recommend doing a comparison first. You can extract your SFMC Subscriber attributes from the hidden system tables (check them all out here: help.salesforce.com/…) via a simple Query and see what differences you have between SFMC and your primary platform. That'll give you an idea of scope, and makes it easier to measure the cost of not having a closed loop. API's can be complex to implement and support, and getting things wrong could be even more expensive in terms of failures in SPAM compliance.
    – Rainer G
    Commented Jun 17, 2019 at 1:54
  • What would be a good measure though? Are you saying if the inconsistency is great enough, it warrants the idea of a complete purge like what I was thinking of? Yeah, which is why if it's possible to not go down the API's route, that would be ideal. Would you have take a different path?
    – Elvin
    Commented Jun 17, 2019 at 3:52
  • Yep, if it's a big enough impact on KPIs it could be worth doing a cleanup and finding a partner to implement a proper API solution for you. Alternatively, if the impact is relatively small it may be sufficient to put a process in place to update individuals manually, which is possible via the All Contacts subscriber records. It's not fun, but it's simple and consistent.
    – Rainer G
    Commented Jun 17, 2019 at 4:00
  • Hmm, Yeah, I think a quick, inexpensive and possibly maintainable fix would be ideal so I'm going to park the idea of the API. So, what you are saying with the update is, rather than actually purging all existing data, we update their statuses to Active? Actually this is going to be tricky because it's practically impossible to try and match and synchronise both side's data for the fact that the data is huge and also it's everchanging.Thus, I was thinking of purging everything and starting from fresh, letting data import without having to maintain any lists/publication list.
    – Elvin
    Commented Jun 17, 2019 at 4:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .