* Marketing Cloud Engagement *

Hi Ashwini, thanks for the detail, and good news, your current setup is basically the point 2 approach done well. 

On point 1, the important one: flattening upstream does not conflict with all campaigns needing the data, it is the opposite. If you pre-shape those related attributes into scalar fields in Data Cloud with a Calculated Insight and activate those instead of the raw related attributes, the data lands flat for every campaign, so no SSJS parsing is needed anywhere downstream. That removes the timeout entirely rather than managing it. If the campaigns only filter on a handful of derived values, model just those in the CI. 

Point 2 (chunking) was simply this: never parse all 300k in one Script Activity run, slice the DE and process one batch per run so each run stays under the script time limit. What you built, an initial load in chunks then hourly deltas of only new or updated rows, is exactly that pattern, so you are on the right track. 

One refinement as volume grows: drive the delta from a reliable last-modified watermark rather than comparing two full DEs, it stays cheap even at millions of rows. But if the Calculated Insight route is feasible, that is still the cleanest long-term fix since it deletes the parsing step altogether.

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.