[SalesForce] Update Subscriber Status Marketing Cloud SOAP API – OverallStatus Error

I was able to get it to work with this SOAP envelope -- without specifying the Lists:

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope>
   <s:Header>
      <!-- REMOVED -->
   </s:Header>
   <s:Body>
      <UpdateRequest>
         <Options>
            <Client>
               <ID><!-- MID GOES HERE --></ID>
            </Client>
            <SaveOptions>
               <SaveOption>
                  <PropertyName>*</PropertyName>
                  <SaveAction>UpdateOnly</SaveAction>
               </SaveOption>
            </SaveOptions>
         </Options>
         <Objects xsi:type="Subscriber">
            <Client>
               <ID><!-- MID GOES HERE --></ID>
            </Client>
            <PartnerKey xsi:nil="true" />
            <ObjectID xsi:nil="true" />
            <EmailAddress>spriggsa@digitalev.com</EmailAddress>
            <Attributes>
               <Name>Email Address</Name>
               <Value>spriggsa@digitalev.com</Value>
            </Attributes>
            <SubscriberKey>aspriggs@degdigital.com</SubscriberKey>
         </Objects>
      </UpdateRequest>
   </s:Body>
</s:Envelope>

In short: "Being sendable" is not a property a subscriber has. How comprehensive you can get an answer to this question depends on your system setup and context.

Whether a specific email to a subscriber is sendable is always determined at send time (meaning that a record unsubscribing/ landing on an auto suppression list the very second before you send could change the outcome). If you try this with script and SQL automations, you will only be able to run these hourly, so you will never have 100% coverage.

And since context is relevant, you will not get a simple yes/ no answer to your question "is subscriber sendable?". It depends.

==

Whether an email is sent out to a particular subscriber is not just determined by the subscriber being on certain lists with a specific status (as you allude to), but also determined by other, more "situational" factors, such as exclusion script on an individual email being present or the type of send classification used (Transactional / Commercial) for a specific sendout, even the data extensions excluded in a sendout manually.

see this post for an attempt at a visualization: Email Send does not send to everyone in Data Extension, no reason for Exclusion

When we limit your question to not take into account super-specific factors such as errors in the email, exclusion script, raiseError() or individual DEs manually excluded, then you approach this topic as follows: Basically, go through the flowchart linked and try to control for each factor as best you can.

"globals" (note this is a made up category, not something official):

• list detective status can to be determined via API through validateEmail ( https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/validateEmail.html), or manually by trying to import data into a list and checking for import errors.

• Subscriber Status on All Subscribers can be determined through SQL or AMPScript lookups (there are ample resources about these e.g. on stackExchange). You specifically are interested in "held" or "unsubscribed" statuses applying. "held" is always global. If "unsubscribed" is really global depends on the Business Unit Settings (= whether you have to check the parent BU or the respective child BU, in the seconds case, special mention to the _businessUnitUnsubscribes Data view: https://help.salesforce.com/s/articleView?id=sf.mc_as_data_view_businessunitunsubscribes.htm&type=5 ).

  Again, these apply in near-real time, and you don't ever have full control when subscribers receive these statuses, as this happens in the backend, consider e.g. list-unsubscription or bounces being reported - you can only always get an approximation if you check this, say, hourly. What matters is what the status is at send time.

• You can have auto suppression configurations that apply (again: at send time) globally, which essentially can be queried the same as All Subscribers, or any Data Extension. You just need to understand how many exist in your system and apply to your context. If more are added, then also more queries need to be added or you lose visibility. So it pays to have a fixed concept for your auto-suppression configurations in mind.

"situationals":

• auto suppression configurations (ASCs) do not necessarily apply globally, but can be set up dependent on the Sender Profile used. If you have a fixed concept to your Sender profiles and related auto suppressions, you can also control for this through making the relevant lookups. Or of course, if you don't have such ASCs.

• Send Classifications: there are only two, commercial and transactional. The key difference is that transactional classification ignores the All Subscribers Status of "unsubscribed", and that other Auto Suppression Configurations could apply.