Sitecore

Sitecore Connect Recipes: Step-by-Step Field Guide

How to use Sitecore Connect on Workato: three recipes with exact trigger, action, and datapill configuration so retries do not clone items.

More Blogs View Experience
IDE with CMS templates on screen Sitecore Notes by Topic doc.sitecore.com Network cables and server lights AWS War Stories docs.aws.amazon.com Code and data on a dark screen Spark & Cloudera Digests Spark / Cloudera docs Robotic hand and human hand nearly touching SMB Column · EZ4YouTech.com EZ4YouTech.com editorial

Sitecore Connect is a recipe workbench on Workato under the Sitecore Cloud Portal. This guide walks through how to use it, which recipes to start with, and the exact clicks you make inside each recipe step.

Executive thesis

Most Connect failures I see are not "Workato is broken." They are soft connections, vague triggers, and field maps that look green in Test but explode on the second retry. If you treat a recipe like a named contract with an owner, an idempotency story, and a stop condition, Connect becomes boring in the best way.

This post is a field guide for platform engineers and integration leads. It covers Sitecore Connect (the Cloud Portal app built on Workato), not the older Sitecore Connect for Content Hub CMP/DAM module alone. You will build three starter recipes with step-by-step configuration, then harden them so retries do not clone Sitecore items.

Sitecore Connect / Workato recipe setup view from official docs
Recipe setup view: name, location, and starting point before you build. Image: Workato Docs (Sitecore Connect runs on Workato) — docs.workato.com

What Sitecore Connect is (and is not)

Sitecore documents Connect as an integration workbench that links Sitecore products to the rest of your stack with a no-code or low-code canvas. Under the hood it is Workato: recipes (trigger + actions), connectors (auth and verbs per app), and projects that group related work.

You open it from the Sitecore Cloud Portal when your organization has Connect enabled. Non-production capacity is capped (Sitecore publishes fair-use task limits for non-prod). Production capacity is higher and billed against your agreement. Do not load-test against production recipes.

  • Use Connect recipes when you need CRM sync, ticket create, Slack alerts, scheduled exports, or webhook fan-out across SaaS tools.
  • Use SCCH CMP/DAM when Content Hub entities and assets must land in XP/XM with Sitecore-native mapping. That is a different installer and a different ops model.
  • Use custom middleware when you need hard idempotency stores, complex branching, or sub-second APIs that recipes cannot own cleanly.

Basics: projects, connections, recipes

Open the app

  1. Sign in to the Sitecore Cloud Portal with an org that includes Sitecore Connect.
  2. Launch Sitecore Connect.
  3. Land on Projects (or create one: name it by environment, for example xm-prod-integrations vs xm-uat-integrations).

Never mix UAT and production connections in the same project. A wrong connection pick in one action is how test data hits live CRM.

Create a connection before the recipe

  1. Open Connections (or Assets > Connections, depending on your Connect UI revision).
  2. Choose the app (Salesforce, ServiceNow, Slack, Content Hub, HTTP, and so on).
  3. Authenticate with the least-privilege account you can defend in an audit.
  4. Name the connection with environment + system + purpose: prod-salesforce-ro-leads, not Salesforce 1.
  5. Save and run the connection test. Do not start a recipe on a failed connection.
Sitecore Connect recipe canvas from Sitecore Documentation
Official Sitecore Documentation recipe canvas for a Connect audience-export flow. Image: Sitecore Documentation — doc.sitecore.com (CDP / Connect)

Recipe anatomy you must get right

Every recipe has:

  • Trigger — when it starts (app event, schedule, webhook, API request, or callable function).
  • Actions — ordered steps that read or write other apps.
  • Datapills — output fields from earlier steps you drag into later inputs.
  • Logic — IF conditions, loops, error handlers, stop.

Starting points I actually use:

  • Trigger from an app for CRM or Sitecore events.
  • Run on a schedule for nightly reconciles.
  • Trigger from a webhook when a custom service must push into Connect.
  • Build an API endpoint when another system must call you synchronously.

Recipe 1: Content Hub publish alert to Slack (step by step)

Goal: when a Content Hub asset reaches an Approved state, post a short Slack message to the content ops channel. No Sitecore item write yet. This teaches triggers, filters, and datapills safely.

Create the recipe shell

  1. In your UAT project, click Create > Recipe.
  2. Name: uat-ch-asset-approved-slack.
  3. Location: the UAT project folder.
  4. Starting point: Trigger from an app.
  5. Click Start building.

Configure the trigger

  1. In the trigger step, search for Sitecore Content Hub (or the Content Hub connector available to your tenant).
  2. Choose an event close to "new/updated entity" or "workflow state change" for your connector version. If your tenant only exposes a generic entity update, you will add a trigger condition next.
  3. Pick the UAT Content Hub connection.
  4. Set entity type to the asset definition you care about (for example M.Asset or your project-specific definition).
  5. Open Set trigger condition (or equivalent filter).
  6. Map the workflow/status datapill. Operator: equals. Value: Approved (exact string from Hub, case sensitive).
  7. Optional: add a second condition that the asset must have a non-empty title.
  8. Save the trigger.

Configure the Slack action

  1. Under the trigger, click + > Action in an app.
  2. Select Slack and your uat-slack-content-ops connection.
  3. Action: Post message (or Send message to channel).
  4. Channel: pick #content-ops-uat from the picker. Do not hard-code a raw channel ID unless you document it.
  5. Message text: switch to the editor and insert datapills, for example:
Asset approved: {{Title}}
ID: {{EntityIdentifier}}
By: {{LastModifiedBy}}
Link: {{PublicLink or Hub UI URL}}
  1. If a datapill is missing, expand the Recipe data panel from Step 1 and drill into the entity schema. Do not type field names from memory.
  2. Click Save.

Test, then start

  1. Open the Test tab.
  2. Either wait for a real Approved event or use the connector's test/sample job if offered.
  3. Confirm Slack received one message with the right title.
  4. Check job history for success and duration.
  5. Only then click Start recipe in UAT.

Promotion tip: clone into the production project, swap both connections to prod, change the Slack channel to the prod ops channel, and retest with a single asset. Never start prod with UAT connections still selected.

Recipe 2: Scheduled Salesforce lead to Sitecore item (deep map)

Goal: every 15 minutes, find new Salesforce leads with a campaign tag, and create or update a Sitecore item under a known folder. This is where soft keys clone items. Read carefully.

Datapill field mapping from Workato documentation
Datapills map trigger outputs into action fields. Drag from Recipe data; do not invent paths. Image: Workato Docs — datapills and field mapping

Create recipe shell

  1. Create recipe uat-sfdc-leads-to-xm-prospects.
  2. Starting point: Run on a schedule.
  3. Scheduler: every 15 minutes. Time zone: the same zone your Salesforce reports use.
  4. Save.

Step 2 — Search leads

  1. Add Action in an app > Salesforce > Search records (SOQL or Search, depending on connector).
  2. Connection: uat-salesforce-ro-leads.
  3. Object: Lead.
  4. Filter: Campaign membership or custom field equals your pilot value, and CreatedDate greater than the last successful watermark if you store one. For a first version, use "Created in last 20 minutes" and accept a little overlap.
  5. Limit: 100.
  6. Save.

Step 3 — Repeat for each lead

  1. Add Repeat for each.
  2. Input list: datapill from Step 2 records collection.
  3. Inside the loop, add IF: Lead Id is present.

Step 4 — Lookup existing Sitecore item by external id

  1. Inside the loop, add an HTTP or Sitecore action that queries items where a dedicated field SalesforceLeadId equals the Lead Id datapill.
  2. If your tenant has a Sitecore XP/XM connector with Search, use that. Otherwise call your own thin lookup API that reads the mapping table. Do not search by lead name.
  3. Store "found item id" in a recipe variable.

Step 5 — Create or update

  1. Add IF condition: found item id is empty.
  2. THEN Create item under /sitecore/content/Site/Prospects with template Prospect. Map:
    • Title <- Lead Name
    • Email <- Email
    • SalesforceLeadId <- Id (required, never blank)
    • Company <- Company
  3. ELSE Update item by id. Map only fields you allow to change. Do not clear SalesforceLeadId.
  4. On both branches, write LastSyncedUtc to now.

Step 6 — Error handler

  1. Wrap the create/update in Handle errors.
  2. On error: post Slack to #integrations-uat with Lead Id + error message, then continue to next lead (or stop if you prefer fail-fast).
  3. Never return success to the scheduler when the whole batch failed silently.

Why this recipe does not clone

The durable key is SalesforceLeadId, not the Sitecore path and not the person name. Retries and overlapping schedules will hit Update, not Create. If your earlier Connect post about soft keys still haunts you, this is the fix in recipe form.

Recipe 3: Webhook intake with signature check

Goal: receive a partner webhook, verify a shared secret header, then create a ServiceNow incident. Use this when a vendor cannot speak Salesforce or Sitecore natively.

  1. Create recipe uat-partner-webhook-snow.
  2. Starting point: Trigger from a webhook.
  3. Copy the generated webhook URL into the partner portal for UAT only.
  4. First action: IF header X-Partner-Signature equals your secret (compare using the formula mode / Workato formula helpers your tenant supports). If your partner uses HMAC, compute the hash in a formula step; do not compare raw body to the secret.
  5. ELSE stop with an error so the partner sees non-2xx and you do not create tickets for forged calls.
  6. THEN ServiceNow > Create incident. Map short description and description from JSON datapills.
  7. Optional: respond with JSON body containing the incident number if you used an API recipe style.
  8. Test with curl from a locked-down jump box, not from a laptop on public Wi-Fi with the secret in shell history.
curl -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "X-Partner-Signature: $UAT_SECRET" \
  -d '{"title":"UAT ping","detail":"connect recipe check"}'

Datapill mapping cheat sheet

SituationDo thisAvoid
Required field empty at design timeMap a datapill or a typed defaultLeaving required fields blank and hoping Test skips them
Nested JSONExpand Recipe data, drill, then dragTyping Steps[1].foo.bar from memory
Need transformFormula mode on the fieldHidden Excel cleanup before the recipe
List of recordsRepeat for eachMapping the whole array into a string field
Optional CRM fieldLeave blank or map null carefullyWriting literal text "null"

Ops hardening before production

  • One project per environment. One connection naming scheme.
  • Job history retention and a weekly review of failed jobs.
  • Alert recipe: on any failed job in prod project, Slack + email the on-call alias.
  • Document the durable external id for every write into Sitecore.
  • Keep a runbook: stop recipe, replay from job id, verify no duplicate item.
  • Task budget: watch non-prod fair use so a runaway loop does not burn the month.

Recipe editor habits that save you hours

After a dozen recipes, the same habits show up on healthy projects. I keep this list taped near the monitor when I am mentoring a new integration owner.

  • Name every step. Default names like "Create record" are useless in job history at 2 a.m.
  • Put the durable key in the step name: Upsert XM by SalesforceLeadId.
  • Prefer one write app per recipe when you are learning. Fan-out recipes hide which system failed.
  • Keep secrets in Connections or environment properties. Never paste tokens into message text "just for UAT."
  • When Test fails, read the step output JSON before you rewrite the map. Half the time the datapill path is one level deeper than you thought.

Workato's recipe editor (the same canvas Sitecore Connect uses) lets you add steps from the canvas plus menu or from the toolbar. Configure the selected step in the side panel, then save. Use the Test view to run a controlled job and inspect each step's input and output. That Test habit is the difference between "it worked on my machine" and a recipe you will start on Monday.

IF conditions, stop rules, and when to call a function recipe

Inline IF blocks are fine for one or two checks. When you start nesting IF inside Repeat inside Handle errors, extract a Recipe function (callable recipe) for the upsert logic. The parent stays readable: search, loop, call function, alert.

  1. Create a new recipe with starting point Build recipe function.
  2. Define input parameters: LeadId, Email, Name, Company.
  3. Move the lookup/create/update steps into that function.
  4. From the parent, add Call recipe function and map the loop datapills into those parameters.
  5. Return the Sitecore item id to the parent for logging.

Stop rules matter. If Salesforce returns zero leads, stop cleanly. If lookup returns two items for one Lead Id, that is data corruption: stop, alert, and do not update either item until a human merges them.

Monitoring and the Monday morning review

Connect gives you job history and project dashboards. Use them. Every Monday I scan production failed jobs first, then long-running jobs, then recipes that show zero runs when they should have fired.

  • Failed job: open the step error, fix map or connection, replay only if the durable key check still holds.
  • Zero runs on a schedule: confirm the recipe is Started, not just Saved.
  • Spike in task count: look for a loop that searches too wide or a webhook retry storm.

Pair this with the idempotency patterns from earlier Field Notes on Connect retries. Recipes give you the canvas. Durable keys give you sleep.

When not to use a recipe

I push teams to recipes for SaaS glue. I push them away when the requirement is a hard transactional boundary across Sitecore and a payment system, when sub-second user-facing APIs need consistent latency, or when the security team forbids a low-code runtime from holding production credentials. In those cases, keep Connect for notifications and use a service you own for the write path.

Further reading

Actionable checklist

  • Split UAT and prod Connect projects and connections
  • Name connections with env + system + purpose
  • Ship Recipe 1 (Hub to Slack) before any Sitecore write
  • Put a durable external id on every Sitecore create/update recipe
  • Add Handle errors + Slack on every write recipe
  • Test with one real record, then start; clone to prod with connection swap
  • Review failed jobs weekly and keep a replay runbook