* Marketing Cloud Engagement *

Since this is SFMC/MobileConnect (Journey Builder, Alpha Sender ID), not core Apex/Flow - this is Marketing Cloud territory, and the consent/Journey questions below sit at the seam between Service Cloud (Contact Point Consent) and Marketing Cloud (Journey Builder), which is exactly the kind of cross-system sync point worth being explicit about. 

1. Should Journey Builder check Contact Point Consent before sending? 

Yes - but the check should be scoped correctly, and that scoping is the actual design decision here. Under UK PECR, a purely transactional message with no promotional content (order cancellation notice, no upsell/cross-sell copy) is generally exempt from PECR's marketing consent requirements, so legally you don't need marketing SMS consent to send it. But "don't legally need consent" isn't the same as "don't check anything" - you still want to confirm the number is valid/deliverable and hasn't been globally suppressed (e.g. customer explicitly said "don't text me at all," a hard bounce/carrier complaint flag, etc.). So check consent, but check the right purpose

, not blanket marketing consent.  

2. Should the SMS still send if SMS Contact Point Consent is Opted Out? 

This depends entirely on what that Opted Out flag actually represents in your data model, and that's the thing to nail down before building rather than assume: 

• If Contact Point Consent is modeled with a single generic "SMS" consent purpose shared across marketing and transactional, an opt-out there is ambiguous you can't tell if the customer opted out of promos specifically or all SMS contact.
• If it's modeled with separate purposes (e.g. "Marketing SMS" vs "Service/Transactional SMS"), Journey Builder should check the Transactional purpose specifically, independent of marketing opt-out status a customer who opted out of promotional texts still generally expects to get their order-cancellation notice.

My recommendation: model (or confirm you already have) a distinct Transactional/Service SMS consent purpose in Contact Point Consent, separate from Marketing SMS, and have the journey's decision split key off that specific purpose. This sidesteps the legal ambiguity entirely rather than making a judgment call in Journey Builder logic. This is a genuine "pause and confirm with legal/compliance + whoever owns the CPC data model" item, not something to default on silently. 

No - and functionally it wouldn't do much even if configured. Alphanumeric sender IDs only support one-way messaging by default because the sender isn't a real phone number carriers can route replies to, so standard keyword-based opt-outs like STOP don't work natively with alphanumeric IDs. There's no inbound path to that Alpha ID for a keyword to catch. Practical implications: 

• Skip keyword config for this Sender ID - it's not reachable for two way interaction, so it's dead config.
• Since the customer can't reply, best practice is to put an alternative contact method in the message body itself (support phone number or a link) so they have some way to react if needed - this is called out as standard practice in MobileConnect implementations specifically because Alpha IDs can't receive replies.
• If any part of your estate does need two way keyword handling (STOP registration, etc.), that has to live on a numeric long/short code, not this Alpha ID separate Sender ID/code entirely if that need exists elsewhere.

One architecture risk worth flagging explicitly: confirm whether the CPC data your journey checks is synced into SFMC via Marketing Cloud Connector (near real time, so there's a sync lag window) or whether you need a real time lookup back to Service Cloud at send time. Given this is triggered off a same day event (order cancellation → immediate SMS), a same day opt-out landing in that lag window is a plausible edge case worth a decision, not an assumption.

You can check here if your Org is a preview instance:   Sandbox Preview Guide

You can verify in Salesforce Trust: 

The transition image you see when page refreshes should be the Winter '27.

Got it - if you need every value, not the latest, then scrap the ROW_NUMBER part. But the batch-time pain is the real signal: SSJS is row-by-row and single-threaded, so parsing every subscriber's JSON in-journey will always be slow (your 20-min batches) and blow the journey timing. The fix is to get that work off SSJS entirely. Two reliable ways, both needing one change: land the related data as ROWS - a normalized child DE, one row per value keyed by SubscriberKey - instead of a JSON array in one cell. 

1. Best for 'all values': AMPscript at send time. Keep that child DE and in the email use LookupRows(childDE, 'SubscriberKey', subkey) with a loop to render all of a subscriber's values inline. Each send only touches that one subscriber's rows - no giant pre-parse job, nothing to time out, and it naturally handles however many values a person has. 

2. Or pre-flatten with a SQL Query Activity. It is set-based (whole dataset at once, minutes not hours), so it scales where SSJS cannot. Concatenate all values per person into one delimited field using the FOR XML PATH pattern - note SFMC's SQL engine does not support STRING_AGG, so FOR XML PATH is the way. Output a flat sendable DE. 

Either path removes the SSJS bottleneck; option 1 usually wins when the value-count per person is unbounded. 

If this sorts it, a Best Answer mark would help the next person hitting the same JB timeout wall 🙂