I'm attempting to use the LogUnsubEvent() to mark the user as unsubscribed in the tracking job, but don't want the user to actually be unsubscribed from the All Subscribers.I'm sending from a Sendable Data Extension without using Publication Lists. I've tried the following script, where I perform the LogUnsubEvent() and afterwards perform the All Subscribers reactivation. It seems that the LogUnsubEvent() occurs too slowly, as I'm receiving an "OK" from the All Subscribers reactivation, but when looking at the subscriber in the All Subscribers, it's "Unsubscribed". I'm wondering if there was a way to delay the re-activation until after the LogUnsubEvent() has actually completed. I'm trying to avoid using Publication Lists if possible.

//Executing LogUnsubEvent    
var subkey = "abc123"
var jobID = 132151
var listID = 51328
var batchID = 95538

var prox = new Script.Util.WSProxy();
var props = [{
        Name: "SubscriberKey",
        Value: subkey
        Name: "JobID",
        Value: jobID
        Name: "ListID",
        Value: listID
        Name: "BatchID",
        Value: batchID
        Name: "Reason",
        Value: "One click unsubscribe"

var logUnsubStatus = prox.execute(props, "LogUnsubEvent"); // StatusCode: "OK"; StatusMessage: "Event posted"

//Re-Activating subscriber
var subscriber = {
    "Status": "Active"

var subObj = Subscriber.Init(subkey);
var subscriberReactivationStatus = subObj.Update(subscriber); // "OK"

2 Answers 2


Generally, if cloud page runs for more than 2 minutes and it gives you run time (time out) error. So I wouldn't suggest you to add any wait activity on top of your script.

I would created an automation with below activities:

  • SQL query activity to fetch the all subscribers whose status is 'unsubscribed' and update the status as 'Active'
  • use data extract activity to extract the data from data extension in a csv format
  • file transfer to move the file from safehouse to SFTP
  • Import activity to update all subscriber list with status as 'Active'.

But as a side note, As per the law you should consent un-subscription.


Likely you want the tracking that comes with LogUnsubEvent in SFMC, but a different system to be your unsubscription master, but a word of note. There are several benefits and caveats to this, but what's important in terms of the code you are looking for:

Your Cloudpage (assuming this is where this code runs) is not the only way you can get unsubscriptions on All Subscribers List. List-unsubscribe header unsubscribes and reply unsubscribes bypass your implementation entirely, so basically "Why bother" - You will need another asynchronous process to find all records, otherwise you will always have some records inexplicably still unsubscribed. Finding those is not possible in real-time due to the de facto processing of list unsub and RRM, which is sent directly to the SFMC backend before you can do anything.

Hence I would perform the action (reactivation) based on your backend (using SQL on the data views, as Naveen pointed out) after you are sure that the other system has received information about consent.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.