The Web Experiences snippet now accepts a lead object and a set of JS options, so a page that already knows who someone is can pass that straight to the widget.
What's Changed and Why
The snippet let you specify a journey (playbookId) and nothing else. Anything beyond that had to be passed as a URL parameter, so a page that already knew who someone was had no way to tell Chili Piper. Concierge's ChiliPiper.submit() has accepted a lead object for years; the Web Experiences snippet now does too.
What You Can Pass
- lead- visitor fields as key-value pairs, so the widget knows who someone is before they type anything
- locale- set the widget language from the page instead of the browser
- accountId, opportunityId, campaignId + status, caseId - identify the Salesforce Account for routing, and relate the booked meeting to the right record
- meetingTypeId- force a specific meeting type
- event- write extra field values onto the calendar Event
- onTriggered,onSuccess,onError- callbacks in the config object, rather than listening for postMessage globally
A field passed via
lead
isn't asked for again. If the page supplies the email, the Send Data Field step skips it.Why It Matters
- In-app: embed Chat and pass the logged-in user, with no "what's your email?" step
- Attribution without URL parameters: read UTM or campaign data from local storage and pass it in at init; it reaches Salesforce without touching the address bar
- Post-booking: someone books, gets redirected to a thank-you page, and Chat loads there with their details already in hand
Things To Note
- Every key in the lead must match a configured Smart Parameter or a data field reference. If one key doesn't match, none of the values are used, and there's no error message. Check each key before you deploy
- Dynamic tags in chat messages don't resolve values passed via lead. To greet someone by name, collect the field in the flow
- The record options are Salesforce-only; there's no HubSpot equivalent in the snippet
Learn more in our Support Article.