Write personalisation once and reuse it across SMS, WhatsApp and push
Winter '27 extends Handlebars and AMPscript in Marketing Cloud Next to SMS, WhatsApp, RCS, in-app, push and landing pages. Write the rule once.
Summer '26 brought AMPscript to email in Marketing Cloud Next. Winter '27 (generally available 12 October 2026) extends both Handlebars and AMPscript to SMS, WhatsApp, RCS, in-app and push, and to landing pages, which also gain custom HTML forms. The stated intent is to reuse personalisation logic instead of recreating rules for each channel.
- Product
- Marketing Cloud Next
- Edition
- edition not stated in the source
- Topic
- Personalisation
- Confidence
- Medium - shown in a credible source
- Last verified
Who this applies to
- Marketers and developers who personalise messages in more than one channel
- Teams migrating from Marketing Cloud Engagement who already have AMPscript they want to keep
- Edition: not stated in the release note summaries we checked
Why it matters
Every channel that has its own personalisation rules is a channel that will drift. The offer logic gets fixed in email and not in SMS, the name-fallback works on the landing page and not in push, and nobody notices until a customer does. One expression, used everywhere, is easier to test and easier to prove compliant.
Try it
- Inventory the personalisation you use in email today: greeting fallbacks, offer eligibility, region-specific content, date formatting. Mark which ones also appear, or should appear, in SMS, WhatsApp or push.
- Decide on one language for shared logic. Handlebars is the native choice in Marketing Cloud Next; AMPscript is the pragmatic one if the logic already exists from Engagement.
- After the Winter '27 upgrade, move one shared rule (a greeting fallback is the safe first pick) into the SMS template and confirm it renders with the same test records you use for email.
- Repeat for landing pages, where the same expressions can now drive dynamic content, and wire a custom HTML form only if the standard form cannot capture what you need.
- Keep a short register of shared expressions with the record fields they depend on, so a field rename does not silently break four channels.
Example use case
A utility sends outage notices by email, SMS and push. The eligibility logic (which customers are on which feeder) was built three times and had diverged. After Winter '27 the team keeps one expression for eligibility and one for the plain-language address line, uses them in all three templates and on the outage landing page, and tests all four surfaces from the same set of test contacts before the storm season.
Prerequisites, limitations and risks
- Winter '27 for the SMS, WhatsApp, RCS, in-app and push support; Summer '26 or later for AMPscript in email
- Each channel must be provisioned. SMS and WhatsApp are add-ons; RCS availability by country is not covered by the source
- Character limits still apply in SMS. An expression that renders three lines in email may render past the limit in a text message
- Edition and permission requirements are not stated in the summaries we used
Documented behaviour above comes from the sources listed below. Availability varies by edition, SKU and region - confirm entitlements in your own org before you rely on a feature.
Sources
- Cross-channel content personalisation with scripting (Winter '27 release notes)
- Landing pages and forms: Handlebars, AMPscript and custom HTML forms (Winter '27 release notes)
- Winter '27 marketing release notes
Stuck on this in your own org?
Blueport is a Sydney-based Certified Salesforce Consulting Partner with 100+ implementations since 2018. If a step above does not match what you see in Marketing Cloud Next, tell us - it is either an edition difference or a change worth knowing about, and we will find out which.
Talk to our team