Rebuilding Quip Live Apps in Slack: The Technical Guide

Rebuilding Quip Live Apps in Slack: The Technical Guide

Quip Live Apps do not convert to Slack canvases. There is no migration tool, no partial transfer, and no workaround that preserves interactivity. When Salesforce's in-product migration flow converts a Quip document to a Slack canvas, Live Apps are silently dropped — no placeholder, no error message, no warning. They vanish.

This is not a failure of the migration tooling. It is a fundamental architectural difference. Slack canvases are markdown document surfaces with no interactive app runtime. Slack's developer documentation states explicitly that Block Kit is not supported in canvases. Canvas content is defined by a document_content object with only one supported type: markdown. There is no iframe, no app container, and no way to embed a component that maintains its own state or connects to an external data source. (docs.slack.dev)

If your Quip estate relies on Kanban boards, calendars, project trackers, Jira embeds, or Salesforce Record Live Apps, every one of those must be inventoried, evaluated, and either rebuilt on a different Slack surface or replaced with a dedicated tool. This is reimplementation work, not a conversion step.

This guide covers what Quip Live Apps are, why none of them survive the move to Slack Canvas, how to inventory your estate using the Quip API, which Slack-native features can absorb which use cases, and how to scope the rebuild before you start migrating content. It also covers custom Live Apps built with the Quip SDK, API pagination for large estates, and the triage logic for deciding what is not worth rebuilding — before you spend time on rebuild paths.

If you are still choosing a destination, see our Quip End-of-Life Playbook. If your destination is confirmed as Slack, see the official Salesforce migration path guide.

What Are Quip Live Apps?

Quip Live Apps are interactive, live-updating applications embedded directly inside Quip documents. They were announced at Dreamforce 2017 as part of the Quip Collaboration Platform. Unlike static content, Live Apps maintain their own data model, render custom UI inside an iframe, and can sync bidirectionally with external systems. Users insert them with the @ key — @kanban, @calendar, @salesforce — and each instance stores its data inside the Quip document that contains it.

The most commonly used Live Apps fall into two categories:

Native (built by Quip/Salesforce)

Third-party (via Salesforce AppExchange)

Custom Live Apps (built with the Quip Live Apps SDK)

A third category exists that often goes undetected until migration: custom Live Apps built by internal developers or third-party consultants using the Quip Live Apps SDK. These are React applications hosted in Quip's iframe runtime. They have their own data model stored in the Quip document's blob store, their own UI, and may connect to internal APIs or databases that have nothing to do with Salesforce or Atlassian.

The Quip Live Apps SDK exposes:

• quip.apps.getRootRecord() — access to the app's root data record stored inside the Quip document
• quip.apps.recordQuipUser() / quip.apps.getViewingUser() — user identity and presence
• quip.apps.openLink(), quip.apps.updateToolbar() — UI surface controls
• quip.apps.auth() — OAuth flow support for connecting to external services

Custom apps appear in the exported HTML with a data-live-app-id value unique to that app (not matching any of the native app IDs), and their payload is stored in data-live-app-payload as a JSON blob. There is no equivalent hosting surface for custom React apps in Slack Canvas. The closest alternatives are:

• A Slack App with an App Home tab — a persistent, user-specific surface that can render custom UI via Block Kit
• A custom step in Workflow Builder — callable from workflows, suitable for form-driven interactions
• A Slack app with a modal triggered from a message shortcut — suitable for point-in-time interactions

None of these are drop-in replacements. Custom Live Apps require the most significant rebuild effort, because the app itself must be ported, not just the data. During inventory, flag any data-live-app-id value that does not match the known native app IDs as a custom app requiring developer review.

Live Apps mix document content with application behavior, and Quip itself documents real failure modes: more than 5 Live Apps in a single document may cause partial exports, more than 10 can degrade performance, large Calendar or Kanban boards can fail to render, Kanban boards above 50 cards may become uneditable, and Project Trackers may not export cleanly to HTML or PDF. This is one reason Live App scoping cannot be delegated to a last-minute export pass. (help.salesforce.com)

Why Don't Quip Live Apps Convert to Slack Canvas?

Slack canvases are a fundamentally different surface. A canvas supports rich text, headings, bullet lists, checklists, code blocks, images, links, and embedded files — but it does not support interactive application components.

The incompatibility is architectural, not a missing feature:

• No iframe runtime. Quip Live Apps execute inside an iframe that the Quip platform hosts and sandboxes. Slack Canvas has no equivalent container. There is no way to embed a runtime application in a canvas element.
• No Block Kit in canvases. Block Kit — Slack's UI framework for buttons, date pickers, select menus, and interactive forms — is explicitly restricted to messages, modals, and App Home tabs. It cannot be used in canvases. An LLM or developer who assumes Block Kit bridges this gap is wrong.
• No live data binding. Canvas content is static at render time. There is no mechanism for a canvas element to subscribe to an external data source, poll an API, or update when a Salesforce record changes.
• No stateful component model. Quip Live Apps maintain their own state (card positions, assignees, form values, calendar events) inside the document's data store. Canvas markdown has no equivalent — there is no place to store and retrieve structured app state within a canvas document.

This means:

• A Kanban board cannot render as a canvas element — there is no drag-and-drop card surface
• A calendar cannot render — there is no date-grid component
• A Salesforce Record embed cannot render — there is no live data binding in the canvas surface
• A Jira embed cannot render — there is no third-party app container
• A project tracker cannot render — there is no stateful progress component
• A custom Live App cannot render — there is no iframe hosting surface

The Quip-to-Slack migration flow that Salesforce provides converts your document text, headings, tables, and lists into canvas markdown. Salesforce's official language states that Live Apps such as Calendar and Kanban "may change appearance" while "preserving data" during conversion. Be careful with the word convert here — a converted canvas may contain preserved information in simplified form, but it is not hosting the original Live App runtime. (help.salesforce.com)

Because the destination surface lacks an interactive runtime, replacing Live Apps is an operational reimplementation project, not a data mapping exercise.

Which Live Apps Are Not Worth Rebuilding?

Before you scope any rebuild paths, apply this triage filter to your inventory. A significant portion of the Live Apps in any Quip estate are abandoned — created once for a project plan that ended two years ago, or a poll that collected three votes.

Apply this decision logic during inventory:

1. Last modified > 6 months ago and no active viewers? Mark as archive-only. Export the document content, note that a Live App existed for the audit trail, and move on.
2. Fewer than 3 active users? Ask the owner if they still need the functionality. The answer is often "I forgot that was there."
3. Duplicate of a tool that already exists in your stack? If your team already uses Jira for sprint planning, a Quip Kanban doing the same thing is redundant. Retire it.
4. Data lives in an external system anyway? If a Salesforce Record embed was pulling live CRM data, that data still exists in Salesforce. You do not need to rebuild the embed — you need to ensure the team knows how to access it via Salesforce for Slack.
5. No owner and no system-of-record value? Retire it. The Quip Admin Audit API (GET /1/admin/audit/events) returns event logs including document_viewed, document_edited, and member_added events with timestamps — use this to confirm actual access patterns beyond the updated_usec field on the thread object. (quip.com)

When a Live App has historical value but no operational value, preserve the history and retire the behavior. Export the document to PDF or HTML — this flattens the Live App into a visual snapshot, preserving the historical state without requiring a rebuild. Quip recommends screenshot fallback for certain Project Tracker export cases. (help.salesforce.com)

How to Inventory Live App Usage Before You Migrate

The single most important pre-migration step is to audit your Quip estate for Live App usage before you begin migrating content. The goal is a scoped list of which documents contain Live Apps, which types, and how actively they are used — so the rebuild is planned rather than discovered.

Using the Quip API to detect Live Apps

The Quip Automation API returns document content as HTML. Live Apps appear in the HTML as elements with specific attributes — including data-live-app-id attributes that identify the app type. Quip's docs note that the same Live App type uses the same data-live-app-id within a company, which means you can label a few samples manually and classify the rest programmatically. Custom Live Apps will show a data-live-app-id that does not match any known native app ID — flag these separately for developer review. (quip.com)

The general approach:

1. List all threads using the Admin API endpoint POST /1/admin/threads/list (requires an admin-scoped access token)
2. Handle pagination — the response includes a cursor field when more results exist; pass cursor as a query parameter on the next call until no cursor is returned
3. Fetch each thread's HTML via GET /2/threads/{thread_id}/html
4. Parse the HTML for Live App elements — look for data-live-app-id attributes, data-live-app-payload data, and Live App class names
5. Classify each instance — match data-live-app-id values against your manually sampled reference set; flag unrecognized IDs as custom apps
6. Record thread ID, title, last-modified date, owner, folder, app types, and custom-app flag into a spreadsheet or database

import requests
from bs4 import BeautifulSoup
 
QUIP_API = "https://platform.quip.com"
HEADERS = {"Authorization": "Bearer YOUR_ACCESS_TOKEN"}
 
# Known native Live App IDs (sample a few docs to populate this from your tenant)
KNOWN_NATIVE_APP_IDS = {
    "kanban": "kanban-app-id",
    "calendar": "calendar-app-id",
    "project-tracker": "tracker-app-id",
    "salesforce-record": "sfdc-record-app-id",
    "process-bar": "process-bar-app-id",
    "poll": "poll-app-id",
    "countdown": "countdown-app-id",
}
 
def list_all_threads():
    """Paginate through all threads using cursor."""
    threads = []
    cursor = None
    while True:
        params = {"cursor": cursor} if cursor else {}
        resp = requests.post(
            f"{QUIP_API}/1/admin/threads/list",
            headers=HEADERS,
            params=params
        )
        data = resp.json()
        threads.extend(data.get("threads", []))
        cursor = data.get("cursor")
        if not cursor:
            break
    return threads
 
def get_thread_html(thread_id):
    resp = requests.get(
        f"{QUIP_API}/2/threads/{thread_id}/html",
        headers=HEADERS
    )
    return resp.json().get("html", "")
 
def detect_live_apps(html_content):
    """
    Returns list of dicts: {app_id, type, is_custom, payload_present}
    """
    soup = BeautifulSoup(html_content, "html.parser")
    results = []
    for el in soup.find_all(attrs={"data-live-app-id": True}):
        app_id = el.get("data-live-app-id", "")
        payload_present = bool(el.get("data-live-app-payload"))
        app_type = next(
            (k for k, v in KNOWN_NATIVE_APP_IDS.items() if v == app_id),
            "CUSTOM"
        )
        results.append({
            "app_id": app_id,
            "type": app_type,
            "is_custom": app_type == "CUSTOM",
            "payload_present": payload_present,
        })
    return results

For a quick shell-level scan across exported HTML files:

# Flag docs containing any Live App
grep -rl 'data-live-app-id' export/*.html
 
# Extract all unique app IDs
grep -oh 'data-live-app-id="[^"]*"' export/*.html | sort | uniq -c | sort -rn
 
# Separate custom apps (IDs not in your known set)
grep -oh 'data-live-app-id="[^"]*"' export/*.html | grep -v -f known_app_ids.txt

API pagination for large estates

The POST /1/admin/threads/list endpoint returns a maximum of 100 threads per call. On estates with thousands of documents, failing to handle pagination results in a silent partial inventory — one of the most common scoping errors in Quip migrations. The cursor is opaque and must be passed verbatim; do not attempt to construct it or infer position from it. The loop terminates when the response omits the cursor field entirely (not when it returns null).

What the inventory should capture

GET /1/threads/{thread_id} returns owner and sharing context. GET /2/threads/{thread_id}/folders lets you attach folder location so the rebuild backlog can be assigned to a team rather than sitting as an anonymous list of document IDs.

Guest access and permissions inheritance

One frequently missed issue: Quip documents can be shared with external guests (people outside your Quip tenant). Slack canvases use a different guest access model — guest access in Slack is channel-scoped, not document-scoped, and is restricted on most plans. If a Quip document with a Live App was shared externally, the rebuilt Slack surface may not be accessible to those same external collaborators without a channel invitation and a guest seat. Capture the shared_member_ids and invited_member_emails fields from GET /1/threads/{thread_id} during inventory to identify externally shared documents before migration.

Rebuild Paths for Each Live App Type

There is no single Slack feature that replaces all Live Apps. The rebuild path depends on what the Live App was actually doing.

Slack Workflow Builder — for process-shaped Live Apps

Slack Workflow Builder is Slack's built-in no-code automation tool. Use it to replace Live Apps that were primarily about moving work through stages: approval processes, request intake, status updates, and notifications.

Workflow Builder supports multiple triggers — links, webhooks, schedules, list-item changes, posted-message keywords, join events, and emoji reactions — and its steps can run native Slack actions, third-party connector actions, or custom steps. Slack also supports embedding workflow trigger links in a canvas, which makes canvas a good briefing surface and Workflow Builder a good action surface. (slack.com)

Plan tier matters: Basic workflows are available on Pro and above. Branching logic (conditional steps), multi-step approvals, and custom steps are restricted to Business+ and Enterprise Grid. Admins can also restrict workflow creation to specific users or groups — confirm your org's settings before designing workflows for end users. (slack.com)

Good fit for replacing:

• Process Bars — Build a workflow triggered by a form submission or emoji reaction that moves a request through defined stages and posts updates to a channel
• Polls — A form step can collect votes; the AI Generate step can summarize results
• Countdown-triggered actions — Use scheduled workflows to post reminders as a date approaches
• Intake forms — Quip documents that functioned as IT support, marketing asset, or legal review request forms

Not a fit for: Anything that needs a persistent visual surface. Workflow Builder executes actions — it does not render a board, calendar, or tracker that people stare at.

The rebuild path for a process-shaped workflow:

1. Analyze the Quip intake. Identify required fields from the legacy Quip document.
2. Build the Slack Workflow. Create a new workflow triggered by a link or channel shortcut. Use the form step to collect the necessary data.
3. Define the output. Configure the workflow to post form data into a specific channel, or write it to a Slack List for the operational team to triage.
4. Update the Canvas. Place the workflow trigger link directly inside the canvas. The canvas acts as the instruction manual; the link initiates the actual process.

Slack Lists — for Kanban boards and project trackers

Slack Lists are the closest native replacement for Quip Kanban boards and project trackers. Lists support custom fields for assignee, due date, status, and priority, with both a Kanban-style board view and table view. They support drag-and-drop between status columns, filtering, grouping, CSV import/export, subtasks, comments, and simple automations such as form intake and field-change notifications. Lists can be embedded in a canvas, so a canvas can hold the narrative while the list holds the work items. (slack.com)

Plan constraints:

• Lists are not available on free Slack plans.
• Slack Lists are capped at 1,000 items (including subtasks) on Pro and Business+, and 5,000 items on Enterprise Grid, after which older items are archived automatically. (slack.com)
• Lists do not support Gantt views, dependencies between items across lists, time tracking, or cross-list rollup reporting.
• For teams with more than roughly 50 active items, complex dependencies, or cross-project reporting needs, a dedicated tool (Jira, Asana, Linear) will serve better.

Good fit for replacing:

• Kanban Boards — Lists offer a native board view. If your Quip Kanban boards were used for sprint planning, task triage, or content calendars, a Slack List is the closest equivalent.
• Project Trackers — Custom fields and status tracking in Lists map directly to what Project Tracker did in Quip.
• Simple Calendars — If your Quip calendar was really a list of dates with owners, a List with a date field and sorted view works.

The rebuild path for Kanban data:

1. The text and context of the Quip document migrate to a Slack Canvas.
2. The Kanban or tracker data is exported (via CSV or by extracting the data-live-app-payload JSON during inventory) and imported into a new Slack List.
3. The Slack List is linked inside the canvas, which provides a clickable entry point with unfurled preview.

For lightweight checklists — simple punch lists or meeting agendas — Slack Canvas natively supports checklists without requiring a Slack List. Canvas checklists have no assignments, no due dates, and no reminders. Do not use them for anything that requires accountability or time-based tracking.

Salesforce for Slack — for Salesforce Record embeds

The ability to embed a live, editable Salesforce record directly into a document was Quip's primary selling point for revenue teams. Account executives used these embeds to update opportunities during pipeline reviews without leaving the document. This specific workflow does not exist in Slack Canvas.

The Salesforce app for Slack is the direct replacement path. It is a free integration requiring installation from both the Slack App Directory and the Salesforce AppExchange (a companion managed package). It lets users search, view, and update Salesforce records inside Slack. On Business+ and Enterprise Grid plans, you can add dynamic Salesforce data to a canvas. (slack.com)

What it covers:

• Searching and viewing records for standard objects (Accounts, Opportunities, Leads, Contacts, Cases, Tasks) and custom objects
• Editing record fields from within Slack, with changes syncing back to Salesforce
• Setting up alerts when record fields change
• Adding Salesforce record data to canvases (Business+ and Enterprise Grid only)

What it does not cover: The integration does not render a full record layout inside a canvas the way Quip's Salesforce Record Live App did. You get a card-style view in messages and a data embed in canvases — not an inline editable form with field-level layout control.

Permissions matter at validation time. Canvas Salesforce embeds are rendered per-viewer based on that user's field-level security and record access in Salesforce. A canvas that looks complete to a Salesforce admin may show incomplete or missing data to an end user with restricted field access. Test with representative users across all relevant permission sets before declaring a canvas migration complete.

If the Quip document was a collaboration space around one account or opportunity, Salesforce Channels can be a better replacement than a generic canvas. Salesforce Channels map Slack channels directly to Salesforce records, creating a bidirectional collaboration space tied to the CRM record. (slack.com)

Implementation requirements:

1. Install the Salesforce for Slack app from the Slack App Directory.
2. Install the companion managed package from Salesforce AppExchange.
3. Map the required Salesforce objects to Slack.
4. Configure custom alerts and message shortcuts so users can update records via Slack channels.
5. Test with real end users across all permission sets — field-level security differences will surface here and not before.

This is a behavioral shift. Revenue teams must be trained to manage pipeline updates via channel-based notifications and modals rather than a centralized, embedded document.

Custom Live Apps (Quip SDK) — the hardest rebuild

Custom Live Apps built with the Quip Live Apps SDK are React applications that execute in Quip's iframe runtime. They have no equivalent hosting surface in Slack Canvas. Rebuilding them requires porting the application, not just migrating data.

Assessment steps before committing to a rebuild:

1. Extract the app manifest — the package.json and manifest.json in the app's source repository describe the app's data schema, toolbar actions, and external API connections.
2. Extract the payload data — the data-live-app-payload attribute in exported HTML contains the app's stored state as a JSON blob. Parse this to understand what data must be preserved.
3. Identify external dependencies — if quip.apps.auth() was used, the app connects to an external OAuth provider; that integration must be rebuilt on the Slack side.
4. Choose a target surface:
   • App Home tab — persistent, user-specific, supports full Block Kit layout; good for tools used regularly by individual users
   • Workflow Builder custom step — good for form-driven interactions triggered on demand
   • Slack app modal — good for point-in-time interactions triggered from a message shortcut
   • External tool embedded via link unfurling — good for read-heavy displays where the source of truth lives elsewhere

Custom Live App rebuilds require a developer. Budget accordingly — a simple custom app (a form with a few fields and a data store) takes 1–2 weeks. A complex app with external OAuth, a custom data model, and real-time updates takes 4–8 weeks.

Jira — keep it as the system of record

If the Quip Live App was showing Jira work, rebuild the work in Jira and use Slack as the conversation layer. Atlassian's Jira Cloud for Slack app can create, update, assign, and preview work items directly in Slack. (support.atlassian.com)

Pasting a Jira issue link into a Slack Canvas unfurls to show the issue status, assignee, and summary. It is not an interactive component. The practical rebuild:

1. Move documentation to Canvas. Migrate the PRD or sprint spec to a Slack Canvas.
2. Use Lists for triage. If the Quip doc was used for bug triage, replace the Quip Kanban with a Slack List, or use Workflow Builder to route bug reports directly into Jira via webhooks.
3. Rely on channel notifications. Configure Jira webhooks to push status updates into a dedicated project channel. The Canvas serves as static reference material pinned to that channel; the channel handles real-time updates.

Trying to compress backlog management into a canvas or lightweight list almost always creates a worse version of Jira that still depends on Jira somewhere else. That is duplicated maintenance, not migration.

Dedicated tools — for anything genuinely project-shaped

If your Quip Live Apps were the center of a real project management workflow — with multiple active Kanban boards, cross-team calendars, Jira sprint embeds, or Lucidchart diagrams — a Slack-native replacement will not match the functionality.

The integration story in Slack is strong — most tools have first-party Slack apps that post updates, unfurl links, and send notifications to channels. What you lose compared to Quip is the single-document surface where everything lived together. What you gain is a purpose-built tool that actually scales.

What Cannot Be Replaced in Slack

Some Quip Live App capabilities have no equivalent in Slack and no clean rebuild path:

• Bidirectional Salesforce editing inside a document surface. The Quip Salesforce Record Live App let you edit CRM fields inline within a shared document. Slack's Salesforce integration lets you edit records, but not embedded within a canvas — it is a separate modal interaction.
• Third-party Live Apps with custom UI. Quip Live Apps built by third parties (DocuSign, New Relic, Smartsheet) via the Quip Live Apps API are React applications hosted in Quip's iframe. There is no equivalent hosting surface in Slack Canvas, and most of these vendors have not built equivalent Slack canvas integrations.
• Custom Live Apps with external OAuth. If a custom Live App used quip.apps.auth() to connect to an internal or third-party API, that OAuth flow must be rebuilt as a Slack app with its own OAuth configuration.
• Single-page working surfaces. Quip's design philosophy was "everything on one page" — a document with a Kanban board, a calendar, a Salesforce record, and meeting notes all visible together. Slack distributes this across channels, canvases, lists, and app integrations. The single-pane experience does not exist in Slack.

For teams where the single-pane experience was the actual value — not any individual Live App — consider whether an alternative destination like Notion or Coda might be a better fit.

The Practical Rebuild Sequence

Once you have your inventory and have triaged what is worth rebuilding, execute in this order:

Step 1: Migrate document content first

Use the Salesforce in-product migration flow or a scripted extraction to move all document content to Slack canvases. Accept that Live Apps will be dropped. The goal is to get the text, tables, and structure into the target.

Step 2: Set up the Salesforce for Slack integration

If your Quip estate used Salesforce Record or List View Live Apps — and most Salesforce-owned Quip instances do — configure the Salesforce app for Slack immediately. This covers the most common class of Live App: embedded CRM data. Install both the Salesforce app from the Slack App Directory and the companion managed package from AppExchange, then map objects and configure alerts before any end users begin working from canvases.

Step 3: Create Slack Lists for active tracking use cases

For each Kanban board or project tracker that passed your triage filter, create a Slack List with equivalent fields. If you extracted the Live App data during your inventory (via the data-live-app-payload attribute or the Export Live App API), you can populate the list by importing a CSV.

Step 4: Build Workflow Builder automations

For each Process Bar, intake form, or recurring poll that needs a successor, build a Slack workflow. Start with the trigger, define the steps, and test with the team that will use it. Confirm plan tier before building branching logic — Business+ or Enterprise Grid is required for conditional steps.

Step 5: Scope and rebuild custom Live Apps

Custom Live Apps identified during inventory require developer involvement. Prioritize by usage frequency (from audit event logs) and business criticality. For each: extract the payload data, document the external dependencies, choose the target Slack surface, and execute as a separate engineering project with its own timeline.

Step 6: Connect dedicated tools for complex use cases

Install the Jira, Asana, Lucidchart, or other Slack apps for any Live App that was serving as a window into an external system. Configure channel notifications and link unfurling so the team gets visibility without leaving Slack.

What This Costs in Practice

Be honest with stakeholders: this is not free. The document migration itself can be scripted and automated. The Live App rebuild is manual scoping, configuration, and testing.

Effort ranges by task type (complexity variables: number of fields, number of users, permission tiers, external integrations):

For a Quip estate with 500 documents and 40 active Live Apps (no custom apps), budget 2–3 weeks of dedicated work for the rebuild phase. Add 4–8 weeks per custom Live App that must be ported.

Scope This as a Separate Workstream

Migrating from Quip to Slack Canvas is not a 1:1 conversion. It is a transition from a document-centric collaboration model to a channel-centric communication model. The document text migrates. The interactive behavior does not.

The teams that handle this well scope the Live App rebuild as a distinct project — with its own timeline, owner, and acceptance criteria — rather than treating it as a footnote on the document migration. Inventory first. Triage ruthlessly (this step alone typically eliminates 40–60% of apparent rebuild scope). Rebuild only what is actively used. Accept that some capabilities will change shape: a Kanban board becomes a Slack List, a Salesforce embed becomes a /salesforce search, a process bar becomes a workflow, a custom Live App becomes a Slack app.

The functionality does not vanish from your organization; it redistributes — and in most cases it moves into tools that are better maintained, better governed, and more scalable than React applications embedded in text documents.

Treat this as an opportunity to clean up shadow IT. Quip made it easy for non-technical users to build fragile, undocumented micro-applications inside text documents. Moving to Slack forces you to standardize those processes into native lists, official workflows, and dedicated systems of record. That is a better outcome than preserving the mess.