Sitecore Sidekick on XM: A Complete First-Week Implementation Guide

Sitecore Sidekick is not a replacement for your content model. It is an accelerator for authors who already know where items live, which templates own which fields, and how workflow gates publishing. If you treat Sidekick as a shortcut on day one, you will get confident-sounding drafts mapped to the wrong field API names. The first week on XM 10.4 should be a controlled pilot: one branch under /sitecore/content/, three roles exercised in order, and edit-distance metrics captured before you widen the blast radius.

Licensing and platform fit: XM Cloud vs XM 10.4

Sidekick licensing sits alongside your XM or XP entitlements. On XM Cloud, Sidekick ships as part of the cloud authoring surface and binds to cloud identity roles. On XM 10.4 on-premises or managed hosting, you enable Sidekick through the Sitecore Marketplace package and map Active Directory or Identity groups to Sidekick-specific roles in the Sitecore role manager.

The practical difference for your first week: XM Cloud authors work primarily in Pages with Sidekick panels embedded in the cloud UI. XM 10.4 teams often split time between Pages (if SXA or headless authoring is enabled) and Content Editor for template debugging. Sidekick suggestions still reference the same field API names regardless of shell, but the panel placement and preview context differ.

• XM Cloud: Sidekick User role assigned via cloud portal; no local IIS config; preview uses cloud Edge endpoints.
• XM 10.4: Sidekick package deployed to CM; roles created in core database; preview may hit local CM hostname.
• XP note: Sidekick does not touch xDB personalization rules in week one. Keep the pilot on static page content.

Before day one, confirm with your account team that Sidekick seats match the number of authors in the pilot, not every developer with CM access. Developers need Sidekick User only if they validate field mappings; otherwise grant read-only CM and skip Sidekick licensing for them.

Roles: Sidekick User, Author, Approver

Sitecore separates who can invoke AI assistance from who can publish. Your RACI for week one should look like this:

Sidekick User

Can open Sidekick panels, accept or reject suggestions, and run rewrite actions on items in scope. Cannot approve workflow items unless they also hold Author or Approver. Assign to content authors and one technical lead who owns field mapping validation.

Author

Standard Sitecore author rights on the pilot branch: create, write, submit. Authors with Sidekick User generate drafts; they still manually review every field before submit. Sidekick does not auto-submit workflow in a well-configured pilot.

Approver

Reviews workflow queue items with Sidekick audit metadata visible (if logging is enabled). Approvers should reject items where AI-filled fields bypassed the synonym guide or exceeded max lengths. No Sidekick User role required for approvers unless they also edit.

Role assignment example in PowerShell (XM 10.4, core DB):

# Assign Sidekick User + Author to content group
Add-RoleMember -Identity "sitecoreSidekick User" -Members "sitecoreCorpAuthors"
Add-RoleMember -Identity "sitecoreAuthor" -Members "sitecoreCorpAuthors"
Add-RoleMember -Identity "sitecoreApprover" -Members "sitecoreCorpLegalReview"

Pages vs Content Editor for Sidekick work

Pages gives authors visual context: placeholders, component labels, and inline field editors tied to renderings. Sidekick panels in Pages write to the datasource item or the page item depending on your SXA or headless setup. Content Editor gives you the raw field list with API names visible in the Configure tab or via the Standard Values dialog.

Week-one rule: technical lead validates mappings in Content Editor; authors operate in Pages once mappings pass QA. If a Hero title keeps landing in the subtitle field, you will spot the mismatch faster in Content Editor than in the Pages preview.

• Use Pages when: validating author UX, placeholder-level prompts, and WYSIWYG fields.
• Use Content Editor when: verifying template inheritance, Standard Values, and field API names against Sidekick field maps.
• Avoid: letting authors switch templates during Sidekick sessions; template drift breaks field maps silently.

Pilot scope: one branch under /sitecore/content/

Pick a single subtree, for example /sitecore/content/Corp/Home/Pilot, with no more than five page types and ten datasource templates. Clone existing production templates into a _SidekickPilot suffix if legal requires separation; otherwise use a dedicated workflow state that blocks publish to web.

Document every template in a pilot registry spreadsheet:

1. Template path and ID
2. Field display name, field API name, type, max length
3. Sidekick prompt ID (if using custom prompt library)
4. Allowed for AI fill (yes/no)
5. Human review required (yes/no)

Exclude computed fields, security fields, and SEO canonical URLs from AI fill in week one. Those fields have high blast radius when wrong.

Template field API names Sidekick must respect

Sidekick maps natural language output to Sitecore fields by API name, not display name. A common failure mode: the display name “Hero Title” maps to API name Title on one template and HeroTitle on another. Standardize before pilot.

Example Hero datasource template excerpt:

Template: /sitecore/templates/Project/Corp/Hero Title (Single-Line Text) max 80 Subtitle (Single-Line Text) max 120 Body (Rich Text) max 2000 CTA Label (Single-Line Text) max 40 CTA Link (General Link) Image (Image)

Sidekick field map configuration (conceptual JSON stored in Sidekick settings item):

{ "templateId": "{A1B2C3D4-E5F6-7890-ABCD-EF1234567890}", "fields": [ { "apiName": "Title", "promptHint": "H1, no brand suffix", "maxLength": 80 }, { "apiName": "Subtitle", "promptHint": "Supporting line, sentence case", "maxLength": 120 }, { "apiName": "Body", "promptHint": "Two short paragraphs, no legal claims", "maxLength": 2000 }, { "apiName": "CTA Label", "promptHint": "Verb-first button label", "maxLength": 40 } ], "bannedTerms": ["guarantee", "best in class", "leading"]
}

Validate maps with a single test item before inviting authors. Run Sidekick once, export field values via PowerShell, compare to expected keys.

$item = Get-Item -Path "master:/sitecore/content/Corp/Home/Pilot/Hero Test"
$item["Title"]
$item["Subtitle"]
$item.Fields.ReadAll()

Workflow integration

Attach the pilot subtree to a dedicated workflow with at least Draft, In Review, and Approved states. Sidekick-filled items should enter Draft, never Approved. Configure workflow command restrictions so Sidekick User cannot use Approve or Publish commands unless you explicitly want that (you do not in week one).

Workflow audit fields worth adding to pilot templates:

• SidekickSessionId (Single-Line Text, read-only via standard values)
• SidekickLastRun (Datetime)
• HumanReviewed (Checkbox, required before submit to In Review)

Approvers filter the workbox on HumanReviewed == 1 before approval. This is a cheap gate that prevents “click accept all” behavior.

Edit distance metrics

Measure how much authors change Sidekick output. Low edit distance means prompts and field maps are tuned. High edit distance on specific fields means remap or rewrite prompts.

Simple metric per field:

edit_distance_ratio = Levenshtein(accepted_text, published_text) / max(len(published_text), 1)

Track weekly aggregates in a spreadsheet or Azure Log Analytics if Sidekick emits events:

• Median edit distance by template
• 90th percentile on Title vs Body fields
• Rejection rate (author discards Sidekick suggestion entirely)
• Time from Sidekick accept to workflow submit

Targets for end of week one: median edit distance under 0.25 on Body fields, under 0.15 on Title, rejection rate under 30%. If Title rejection exceeds 50%, your prompt likely ignores max length or brand voice rules.

Day-by-day first week plan

Day 1: Install, roles, and field registry

Deploy Sidekick package (XM 10.4) or confirm cloud entitlement. Create roles. Build template field registry for pilot subtree. No author access yet.

Day 2: Field map QA in Content Editor

Technical lead runs Sidekick on three test items per template. Fix API name mismatches. Document banned terms with legal.

Day 3: Two author shadow sessions

Authors work in Pages with lead observing. Log panel errors, wrong field fills, and UX friction. Do not widen scope.

Day 4: Workflow and approver dry run

Submit five items through In Review. Approvers reject at least one intentionally to test feedback loop. Verify Sidekick audit fields.

Day 5: Metrics review and go/no-go

Compute edit distance. Triage top three failing fields. Decide whether to add templates or hold for prompt tuning.

Troubleshooting common failures

Sidekick panel missing in Pages

• Confirm Sidekick User role on the account testing.
• Verify Sidekick feature flag in App_Config/Include/Feature/Sidekick (XM 10.4).
• Check item security: user must have write on datasource item.
• Clear browser cache; cloud tenants may need role sync up to 15 minutes.

Wrong field mapping

• Compare Sidekick map template ID to actual item template ID (inheritance may differ).
• Check for duplicate API names across template sections; Sidekick may target the wrong section.
• Ensure Rich Text fields use the correct field type in map, not Single-Line Text.
• Re-run after removing stale Standard Values that overwrite Sidekick output on save.

Suggestions ignore max length

Add hard truncation in post-processing rules if Sidekick settings support it; otherwise enforce in prompt hints and reject oversize in validation script before submit.

function Test-FieldLength($item, $fieldName, $max) { $val = $item[$fieldName] if ($val.Length -gt $max) { throw "Field $fieldName exceeds $max chars ($($val.Length))" }
}

Authors see different panels

Pages experience depends on rendering host configuration. Align CM and CD hostname settings if preview fetch fails silently.

Configuration checklist before wider rollout

After week one, promote learnings to a runbook section in your ops wiki. Keep the pilot branch until edit distance stabilizes for two consecutive weeks.

Sidekick settings item and App_Config

On XM 10.4, Sidekick configuration typically lives in a settings item under /sitecore/system/Settings/Feature/Sidekick plus include files under App_Config/Include/Feature/Sidekick/. Cloud tenants manage equivalent settings in the cloud admin portal. Do not scatter prompt overrides in multiple items; one settings item owns global banned terms, default tone, and retrieval scope roots.

Include file patch example for CM-only feature flag:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"> <sitecore> <settings> <setting name="Sidekick.Enabled" value="true" /> <setting name="Sidekick.PilotRoot" value="/sitecore/content/Corp/Home/Pilot" /> <setting name="Sidekick.LogLevel" value="Information" /> </settings> </sitecore>
</configuration>

The PilotRoot setting gives you a single switch to widen or narrow Sidekick write scope. Custom pipelines can reject Sidekick save events when the item path falls outside that root, even if an author navigates away from the pilot folder manually.

Custom pipeline: block out-of-scope Sidekick saves

Hook item:saving on CM to enforce pilot boundaries and field allow lists:

public void Process(ItemSavingEventArgs args)
{ if (!IsSidekickSession(args)) return; var item = args.Item; if (!item.Paths.FullPath.StartsWith(_pilotRoot)) { args.CancelEdit(); throw new InvalidOperationException("Sidekick writes restricted to pilot branch."); } foreach (Field field in item.Fields) { if (!_allowList.IsAllowed(item.TemplateID, field.ID) && field.WasUpdated()) { args.CancelEdit(); throw new InvalidOperationException($"Field {field.Name} not AI-writable."); } }
}

This pattern saved a regulated client when an author ran Sidekick on a legal disclaimer template that was not in the pilot registry. The save was blocked before workflow submit.

Pages shell: datasource resolution paths

In Pages, Sidekick targets the focused component datasource when a rendering is selected. When nothing is selected, some configurations fall back to the page item. Document which case your project uses because prompt context changes.

• SXA Pages: datasource usually under local Data folder; Sidekick retrieval should include sibling datasources as negative examples (do not duplicate FAQ text from adjacent component).
• Headless Pages on XM Cloud: component map drives field editors; verify JSON field keys match Sitecore API names in Sidekick maps.
• Experience Accelerator + custom renderings: custom experience buttons may open Content Editor for certain templates; train authors to return to Pages after fixing datasource assignment.

Audit logging for approvers

Enable Sidekick session logging to SQL or Application Insights. Minimum event properties: SessionId, User, ItemId, TemplateId, Action (generate, accept, reject, rewrite), FieldApiNames, PromptVersion. Approvers viewing the workbox need a report link, not log file access.

Sample Kusto query for override patterns:

SidekickEvents
| where Action == "accept"
| extend editDistance = todouble(Properties.editDistance)
| summarize avg(editDistance), count() by TemplateId, FieldApiName
| order by avg_editDistance desc

Spikes on a single field after a prompt change show up within hours if logging is wired on day one.

Multi-language pilot constraints

Do not add languages in week one. Sidekick field maps and edit distance baselines are hard enough in one language. If you must support EN and FR, duplicate pilot items per language and tag language in the registry. Never assume translated Standard Values propagate to Sidekick output; authors may see EN suggestions on FR items if language context is missing from the panel.

Security and item ACLs

Sidekick respects Sitecore item security. If authors see “panel unavailable” on specific items, check read/write on both page and datasource. Approvers with read-only access to draft fields cannot see Sidekick-filled content in preview; grant read on draft versions without granting Sidekick User if policy requires.

Comparison with manual authoring baseline

Before day three, time five manual Hero and FAQ datasources without AI. Record median minutes to first valid save. Compare to Sidekick-assisted flow on day four. Leadership expects percentage improvement; engineers should report generation latency separately from author edit time so you do not optimize the wrong bottleneck.

When to widen the pilot after week one

Widen only if: median edit distance under threshold for five consecutive days, zero Sev-2 incidents (wrong legal copy published), approver override rate under 15%, and field map coverage at 100% for templates in the next branch. Add five templates per week, not entire site sections.

Actionable checklist

• Confirm Sidekick licensing seats for pilot authors only.
• Map Sidekick User, Author, and Approver roles before opening Pages to content team.
• Limit pilot to one branch under /sitecore/content/ with five or fewer page types.
• Publish template field registry with API names, max lengths, and AI-fill yes/no flags.
• Validate field maps in Content Editor on three test items per template.
• Wire workflow with HumanReviewed checkbox gate before In Review.
• Track edit distance, rejection rate, and time-to-submit daily.
• Document banned terms and legal constraints in Sidekick prompt config.
• Run approver dry run with intentional rejection to test feedback loop.
• Hold go/no-go on day five using median edit distance thresholds.