Migrate from Stonly to Salesforce Service Cloud

Stonly Guides map to Salesforce Knowledge Articles (KnowledgeArticleVersion). Each Guide becomes a draft Article published to a matching Salesforce Knowledge category. We export step text, media attachments (images and videos as ContentDocument), branching tree nodes (as structured JSON in the Article body), targeting rules, custom CSS, and in-guide variable configurations. The Guide title becomes the Article Title; Guide URL slug maps to the Article UrlName. Note that Salesforce Knowledge does not natively render branching decision trees — branching step content is flattened into the Article body with a documented node map so the content team recreates the logic manually.

Stonly Knowledge Bases map to Salesforce Knowledge DataCategoryGroup structures and Topic hierarchies. We export the full KB hierarchy including category names, descriptions, ordering, and the mapping of which Guides belong to which category, then configure matching DataCategoryGroup top-level categories and sub-categories in Salesforce Knowledge. TopicAssignment records link Articles to Topics for navigation.

The Stonly Widget is a site-side JavaScript snippet that launches Guides on external websites. Widget configuration (default language, widget display name, launcher position, custom colors) is exported as structured JSON. We document the equivalent Embedded Service setup in Salesforce: the Deployment object (Lightning Web Component container), the Channel property for web, and the SiteAsGuestUser access requirements. Widget-level custom properties and user property names are preserved in the export manifest for the admin to re-implement in Embedded Service.

Stonly Triggers define when and to whom Guides are shown based on URL, user actions, or user property conditions. We export each Trigger as structured data including the targeting criteria, guide assignment, trigger type (page load, button click, property match), and any conditional branching. Salesforce has no direct equivalent — Omni-Channel Routing uses Work Item assignment based on presence configuration and capacity, while Guided Action Flows use screen flows for agent-facing decision trees. We document every Trigger with a recommended Omni-Channel or Flow equivalent and deliver the mapping as part of the post-migration handoff inventory.

Custom user properties in Stonly (e.g., subscription_tier, billing_date, product_version) are exported with property names, data types, and value mappings. We create matching custom fields on the Salesforce Contact object for customer-facing properties and on Account for account-level properties. User property targeting rules in Stonly Triggers map to Salesforce formula fields or Flow criteria that evaluate these custom field values at runtime. The complete property schema is delivered in the mapping manifest.

User events (e.g., purchased_product, created_ticket, plan_upgraded) are exported as event names and schemas with any event-based guide routing rules documented. In Salesforce, these map to custom fields on Contact (for event history) or to Campaign Member Status fields (for lifecycle event tracking). Event-based guide routing from Stonly does not have a direct Salesforce analog and is documented in the Flow rebuild inventory.

Stonly's AI-powered search bar surfaces answers from Guide content with query routing rules and fallback behavior. We export the AI Answer configurations including knowledge base scope, routing rules, and fallback settings. Salesforce Einstein for Service Cloud (a separate paid add-on) provides Einstein Search and Einstein Agent capabilities; we document the equivalent configuration including knowledge article scope, search ranking, and escalation rules. Einstein is not included in the base Service Cloud license — we flag this as a scope item during discovery.

Stonly provides full-path analytics including guide completion rates, step-level drop-offs, and usage trends by guide, category, and time period. We export analytics snapshots as CSV at cutover (guide-level completion rate, view count, average time per step, drop-off step for each guide). Historical analytics cannot be re-imported into Salesforce — we deliver the CSV as a reference file for the admin to build equivalent Salesforce Reports and Campaign analytics post-migration.

Stonly team members (names, email addresses, roles: Admin, Editor, Viewer, and KB-level access permissions) are exported as CSV. Role name mappings between Stonly's permission model and Salesforce Profiles and Permission Sets are documented in the mapping manifest. Knowledge article creation and editing access in Salesforce is managed via the Knowledgetab permission and article type sharing settings, which differ from Stonly's role-based access model.

Guide-to-PDF export is available only on Stonly Business and Enterprise plans. If the customer used PDF exports as their primary external documentation format, we confirm this at scoping and flag the feature gap. Salesforce Knowledge articles support browser print-to-PDF natively; organizations requiring programmatic PDF generation evaluate Docmosis, Conga, or S-Docs as AppExchange options. We note this as a rebuild item in the handoff inventory.