CRM documentation: what to write down before and after go-live

CRM documentation is the customer-owned record of how your CRM is configured and how each role uses it. For a US company of about 20 to 100 people, that record is a register of process maps, field rules, security, integrations, role-based guides, an admin runbook, and a go-live handover pack. Vendor help explains the standard product. Your pages name your stages, columns, and integrations. If you are about to accept a Dynamics 365 or Odoo rollout, require that pack before go-live, with a named owner and a review date on every row.

People who type "crm user guide pdf" into a search box are usually looking for a printable manual. Microsoft and Odoo publish the standard manuals as web pages, and Odoo ties those pages to a version number. Your manual is shorter: the path your team takes through your stages, with your required fields and your security roles. A mail-merge layout built from Dynamics 365 Word templates, and Salesforce's "Free CRM Template (for Excel)", are output files. Mention them in the register only as a pointer, and keep them out of the handover section that describes configuration.

A CRM documentation template you can copy

The register below is a working list for an implementation. Microsoft and Odoo do not publish it as a required template under this name. Success by Design is Microsoft's methodology-agnostic framework for Dynamics 365 projects. Microsoft recommends it for all of those projects, FastTrack for Dynamics 365 uses it, and Microsoft states that the framework does not assure implementation outcomes. It maps the work to Discover, Initiate, Implement, Prepare, and Operate. The Solution Blueprint Review and the Go-live Readiness Review are mandatory reviews inside that framework.

Use the Prepare-phase artifacts as the project half of this register. Use the other rows for the configuration your team will still need after the partner's last week.

Copy the table into the project folder and put one owner on every row. A row without a name is still open.

• Scope and CRM process documentation (Purpose: Stages, handoffs, and the definition of done for a lead, opportunity, case, or activity · Typical owner: Operations lead · Where it lives: Project folder, linked from the governance log · Update when: A stage, team, or handoff changes · Owned by: Customer)
• Field and choice dictionary (Purpose: Every custom column, choice label, requirement rule, and tooltip text · Typical owner: CRM admin · Where it lives: Same folder as the solution notes · Update when: A column or choice is added or renamed in the app · Owned by: Customer)
• Security and environment matrix (Purpose: Who may enter development, test, and production, and which security roles they hold · Typical owner: CRM admin, with the IT manager · Where it lives: Admin runbook · Update when: A role, team, or environment changes · Owned by: Customer)
• Automation notes (Purpose: Cloud flows, automated actions, server actions, and the records they touch · Typical owner: Admin who builds them · Where it lives: Admin runbook · Update when: A flow or action changes · Owned by: Customer)
• Integration and custom-module list (Purpose: Mailboxes, EDI or other connectors, partner modules, and in-house modules, with the maintainer · Typical owner: IT manager · Where it lives: Admin runbook · Update when: A connector or module changes · Owned by: Customer)
• User guides by role (Purpose: Clicks for sellers, service reps, and managers on your configuration · Typical owner: Operations lead · Where it lives: Shared drive or intranet, one file per role · Update when: A process step or required field changes, and at each product release or upgrade test · Owned by: Customer)
• Admin runbook (Purpose: Publisher prefix, schema names, solution size, environment list, backup and restore notes · Typical owner: CRM admin · Where it lives: Admin runbook, access limited · Update when: Metadata is created, or an environment is added · Owned by: Customer)
• Cutover plan and go/no-go (Purpose: Tasks, owners, durations, dependencies, and the criteria that stop the cutover · Typical owner: Project owner · Where it lives: Handover pack · Update when: Every mock go-live, then the real cutover · Owned by: Customer accepts; partner drafts)
• Support model (Purpose: Who answers which ticket in the first weeks, and how severity is set · Typical owner: Operations lead and the partner · Where it lives: Handover pack · Update when: The support window changes · Owned by: Customer after acceptance)
• Release or upgrade test log (Purpose: What you retested, what you rewrote in the guides, and what you turned on · Typical owner: CRM admin · Where it lives: Admin runbook · Update when: Each Dynamics 365 release wave, or each Odoo upgrade · Owned by: Customer)

On CRM implementation governance, the same idea shows up as decision rights: a document with no owner is a decision nobody can reopen later. Tie each row to a person who still works for you after the project closes.

Where the CRM user guide for your product lives

Vendor user docs are the baseline. Link them from your guide, and write your own steps beside them. The official page describes the product Microsoft or Odoo shipped. It does not describe the app you configured.

For Dynamics 365 Sales, start at Welcome to Dynamics 365 Sales for the product overview, then send end users to Learn the basics of Dynamics 365 Sales. Those steps match the out-of-the-box Sales Hub and Sales Professional apps. If you renamed the site map, added columns, or changed which roles see which forms, those clicks belong in your role guide. There is no separate customer PDF that already contains your configuration.

Customer Service is split by job. Welcome to Dynamics 365 Customer Service points admins to the Copilot Service admin center for setup, unified routing, channels, and analytics, and points representatives to the Copilot Service workspace. Customer Service Hub is deprecated for new organizations with Enterprise licenses. Write the admin guide against the admin center, and the representative guide against the workspace your new org will use. If a partner's draft still says Customer Service Hub, ask them to show the app name on a new Enterprise trial before you accept the guide.

Odoo splits documentation into User Docs, Install and Maintain, and Developer. The documentation root currently serves Odoo 19.0. The Odoo 19.0 CRM chapter covers pipeline, lead capture, assignment, forecasting, and day-to-day activities, and it points to a tutorial course. User Docs describe standard apps. Studio fields and custom modules are absent from that chapter. Pin every link in your guide to the major version running in production. If production is 18.0, open the 18.0 CRM chapter, not the 19.0 page, or the screenshots will drift from the database your team logs into.

A workable user guide for one role passes a content test: the records that role creates, the fields they must fill, the stage they move, and who they hand the record to. Link the vendor chapter at the top. Screenshot your form, not the demo data in the vendor article. Store the file where the role already works. A PDF on a partner's laptop fails the test the day that laptop is gone.

Field rules users can see in the product

Write each field rule twice. The short line is what the user sees on the form. The long line is what an admin needs when someone argues about a blank value.

In Dataverse, each column has a Description property under Advanced Options. Microsoft says that text appears as a tooltip in model-driven apps when a user hovers the column label, on the create and edit columns page. Put the one-sentence rule there, for example: Required once the opportunity reaches Propose. Use the customer's legal name. The dictionary holds the rest: who may edit it, which security role can clear it, and what each choice means for reporting.

Making a column Business Required blocks save in the app. People who do not know the answer will type anything that lets them save the row. If the rule applies only once the opportunity reaches Propose, leave the column optional on a new lead. Enforce it with a stage rule, a business process flow, or a form that appears later, and say so in the dictionary. Otherwise the pipeline fills with invented values your forecast will treat as real.

In Odoo Studio, the Help Tooltip is the in-app line. It shows when the user hovers the question mark next to the label, as described in Fields and widgets. New Studio fields are prefixed x_studio_ by default. The technical name can be edited in Studio only while the field is being created. Later changes go through Settings, Technical, Fields. A later change still has to keep the x_ prefix, so write the technical name into the dictionary on the day you create the field.

Studio shows 21 field-type choices in the UI while the framework has 15 field types, because some types appear more than once with a different default widget. Studio fields are real database columns. Property fields are not columns. They apply only to records that share the same parent. Put property fields in their own subsection of the dictionary, with the parent they depend on. If you list them as ordinary columns, an upgrade test will look for a database column that is not there.

A column's schema name in Dataverse cannot be changed after the column is created. The solution publisher prefix is there to avoid naming collisions, and it should be set before any new metadata is created. Both points are in Microsoft's solution concepts guidance, and both belong in the admin runbook before the first customization workshop. Assume eight new opportunity columns and a prefix that is still the default: you will live with those schema names for the life of the environment.

CRM process documentation, owners, and the product clock

Owners follow the clock the product already runs on. A standing monthly meeting adds little if nobody opens the release plan or the upgrade page.

For Dynamics 365 Sales, Customer Service, Field Service, related cloud apps, and Power Platform, Microsoft ships two release waves a year, on the release schedule. Wave 1 covers April through September. Wave 2 covers October through March. Early access is for validation in a non-production environment before production.

Release plans label how a feature turns on: automatically for users; automatically for admins, makers, or analysts; or only after an admin, maker, or analyst enables it. Read that label before you rewrite a guide. A feature that turns on by itself can change a form your users already know. A feature that waits for an admin can stay off until you have tested it and updated the guide.

For 2026 release wave 1, Microsoft published English release plans on March 18, 2026, additional languages on April 3, 2026, and general availability starting April 1, 2026. Dates in a release plan can still change, and a planned feature can fail to ship. As of October 2026, treat that March-to-April window as the working pattern for wave 1: read the plan when it posts, validate in early access on a non-production environment, update the user guide and the test log, then let production receive the wave. Put the same review on the calendar for wave 2, which opens in October. The CRM admin owns the test log. The operations lead owns the wording in the role guides. The project owner accepts the change only after someone has clicked through the affected stage on a non-production copy.

Odoo publishes an end of standard support for each major version. Each major version has three years of standard support on Odoo Online, Odoo.sh, and on-premise. Extended support starts when standard support ends, costs an extra fee, and is only on Odoo.sh for a limited set of versions and on on-premise for any version. As of October 2026, the support page lists these ends of standard support: Odoo 19.0 in September 2028 (planned, released September 2025), Odoo 18.0 in September 2027 (planned, released October 2024), Odoo 17.0 in September 2026 (released November 2023), and Odoo 16.0 in September 2025 (released October 2022). Record the end date for the version you run. Do not treat the years after that date as covered until you have a written extended-support arrangement.

On Odoo Online, a database on a major version must be upgraded every two years. A database on a minor SaaS version must be upgraded a few weeks after the next version, and minor versions are usually released every two months. Odoo says that after the first three years you have another two years to complete the upgrade. That second window is a deadline for the upgrade work. It is separate from the paid extended-support offer. Put both sentences in the admin runbook so nobody plans as if year four and year five were free standard support.

The custom-module maintainer is a different owner from the person who schedules the standard upgrade. An Odoo database with custom modules cannot be upgraded until those modules exist for the target version. Odoo Enterprise upgrade of standard apps to the newest version is free. Studio customizations are covered while Studio and the subscription stay active. Partner or in-house modules without a customization-maintenance subscription are not covered. Training on the new version is not included. A breaking change in a standard app is the custom-module maintainer's job to fix. Name that person in the integration row before go-live. If the name is the partner and the contract ends at go-live, you do not have a maintainer.

Assume a 32-person services firm on Odoo 18.0 Online, with Studio fields on the lead form and one partner module for a pricing worksheet. Standard support for 18.0 runs to September 2027 on the published plan. The operations lead owns the role guides and rewrites them from the upgrade test. The partner, or an in-house developer you retain, owns the module and must deliver it for the target version before the upgrade can run. The CRM admin owns the Studio tooltips and the technical names. Training hours for the new version are a separate line you buy or deliver yourselves.

What the solution file contains, and what the admin runbook must say

A Word template, an Excel CRM file, and a Power Platform solution do different jobs. A Word template produces a document from a record. An Excel CRM template is a spreadsheet of contacts and a pipeline. A Power Platform solution is the package of metadata you move between environments.

In Dataverse, solutions are the application lifecycle package. They hold metadata and some configuration tables. Microsoft states that solutions do not contain business data. A solution can include tables, columns, apps, site maps, flows, plug-ins, and similar components, but not every system table. Accounts, leads, opportunities, and cases stay in the environment. Ask for the solution files, and ask separately for the data-migration files, the import maps, and a count of rows loaded in the mock cutover. If the partner says the solution export is the backup of your customers, stop and split those deliverables.

Unmanaged solutions are the development source and should be checked into source control. Managed solutions are the deployment artifact for test, UAT, SIT, and production. Deleting a managed solution removes its customizations and extensions, including data stored in custom tables and custom columns that were part of that solution. The admin runbook should say who is allowed to delete a solution in production, and it should say that deletion is a data-loss event for those custom columns. A Power Platform solution can be up to 95 MB, per the same solution concepts page. Note the current size at handover so the next flow or plug-in does not fail on the cap with no warning.

When a Dataverse environment is created, the choice to install Dynamics 365 apps such as Sales matters at creation time. Microsoft says those apps cannot be installed or uninstalled later. Write the choice into the environment list when the environment is created. Recreating production later so you can add Sales is a new environment, and the data conversation starts over.

Microsoft's access table for application lifecycle management is the security half of the same runbook. Development environments are for makers and developers, not app users. Test environments are for admins and testers, not makers or production users. Production is for admins and app users, and makers should not have maker access there. After go-live, a seller who can still publish a form in production will change the guide without telling the owner. Match the matrix to those three rows and review it when someone changes jobs.

The handover pack to require at go-live

By the Prepare phase, Microsoft expects the team to have finished user acceptance testing and training, customer approvals, information-security reviews, a cutover plan with go/no-go criteria, mock go-lives, a support model, and a deployment runbook that lists tasks, owners, durations, and dependencies. That list is the core of the partner handover for a Dynamics 365 CRM project. Ask for each item as a file you can open, with your company's name on the scenarios. Keep any methodology slide in the steering folder, separate from the files your admin will run.

Require these files before you sign the go-live approval:

1. The deployment runbook, with tasks, owners, durations, and dependencies, written so your admin can run the next deployment without calling the author.
2. The cutover plan and the go/no-go criteria, plus notes from at least one mock go-live that used a copy of your data.
3. The support model for the first weeks: named people, hours, and what counts as a defect versus a new request.
4. UAT evidence: the scripts, who ran them, and which defects were still open.
5. The environment list, including whether Dynamics 365 apps were selected at creation, and who has maker access where.
6. The unmanaged solution in source control, the managed solution deployed to production, the publisher prefix, and the schema-name list for every custom column.
7. A one-line statement that the solution holds no accounts, leads, or other business data, plus the separate data-migration record.
8. Role-based user guides and the field dictionary, accepted by the operations lead, with vendor help linked and your screenshots in place.
9. If the design includes an agent that drafts replies or updates records, the extra go-live checks Microsoft describes for those Dynamics 365 solutions: pre-production agent validation, a documented responsible-AI sign-off, monitoring and alerting, and an incident-response plan for agent behavior after deployment. A consultant reviews that sign-off with you. The document is still yours.

For Odoo, ask for the same operational files even though Success by Design is a Dynamics 365 framework. Add the version pin (the documentation URL for the major version in production), the list of Studio technical names, the list of custom modules and who maintains them, and a written note on whether a customization-maintenance subscription covers those modules. Training on the next version is not part of the standard Enterprise upgrade. If you want it, it is a line in this pack or a later statement of work.

A slide deck that summarizes the project is useful in a steering meeting. It does not replace items 1 through 8. If the deck is all you have, the configuration still lives with the people who built it. That is the point to pause acceptance. Our CRM implementation work treats this pack as a phase deliverable: discovery, configuration, data migration, role guides, and a handover your admin can run. On a Dynamics 365 Sales rollout, the same pack is the acceptance line for the CRM phase: the Sales Hub or Sales Professional steps stay in the role guides, and your fields, stages, and security stay in the dictionary. If you are deciding whether the current partner can finish the pack, read when to hire a CRM consultant and compare the files you hold with the list above. Our target for a first usable phase is 8 to 12 weeks, scoped to the rows you can accept in that window, and that target is ours.

What to rewrite when the product changes

The test log is the document that keeps the others current. Put the next wave or upgrade on the calendar before users find a button that moved.

On Dynamics 365, the sequence is fixed by the release schedule. When the wave plan is published, the CRM admin marks each feature that touches your app as user-on, admin-on, or admin-enabled. Early access happens in a non-production environment. The operations lead updates only the role guides whose screens changed. Features that can still slip or drop out of the plan stay marked as planned until you see them in your tenant. Production receives the wave after that pass, and the test log records the date, the environment, and the guides you edited.

On Odoo, use the vendor's own upgrade test list. Retest views, reports, website pages, record create and edit, mail templates, translations, filters, exports, external integrations, cross-app flows, automated actions, and server actions. Rehearse the production upgrade the day before. Production is unavailable during the upgrade. On Odoo Online, the upgrade cannot be reverted once you have requested it. Because of those two constraints, rehearse the upgrade and rewrite the guides before you request it. The upgrade documentation is the checklist to paste into your test log, with a column for pass, fail, and the guide section you changed.

Split the rewrite. Standard-app changes go to the operations lead. Studio tooltip and technical-name changes go to the CRM admin. Custom-module failures go to the maintainer named in the integration row. If that maintainer cannot deliver the module for the target version, the upgrade does not have a date yet. Scheduling the database upgrade for a weekend, without that module ready, is how teams discover the block on the day production is already set to stop.

CRM adoption follows this loop. People use a guide that matches the screen in front of them, and they stop using a guide that still shows last year's stages. The review date on the user-guide row is the control: the wave plan plus early access for Dynamics 365, and the upgrade rehearsal for Odoo.

How to start from the files you have this week

Open the project folder and the partner's last email. Drop each file you can find into a row of the register. A process map with no owner, a solution zip with no source-control link, and a user guide that still shows standard stages all count as open. You do not need every row finished to see the shape of the gap.

Then do three passes, in order. First, freeze metadata rules: publisher prefix or x_ technical names, and a dictionary row for every custom field already in production or UAT. Second, write the cutover plan to the level of tasks, owners, durations, and dependencies, and run one mock with a restore point you have timed. Third, assign the release or upgrade owner and put the next wave date, or the Odoo version's end of standard support, on the same page as the user-guide review.

If a bidder is still in the proposal stage, ask them to price the handover pack as its own acceptance line: runbook, go/no-go, support model, source-controlled unmanaged solution, managed production solution, field dictionary, and role guides. Data migration stays a separate line, because the solution will not hold it. Ask the response to name the people who will write each file and the hours those people have on the project.

Bring the marked-up register to a working session when more than a few rows are blank, when custom modules have no maintainer, or when go-live is already on the calendar. We will order the missing files against your phase plan and tell you which ones block acceptance.

How Flectic can help

At Flectic, we set up Dynamics 365 Sales around how your team sells, with clear stage rules and quotes on the opportunity. Flectic sends a written proposal with a fixed price for each phase before work starts. Use the Dynamics 365 Sales implementation to see how that discovery work is scoped. The next step is to book a free discovery call with Flectic.

Sources

• Introduction to the Success by Design framework, Microsoft, October 2026
• What is the Dynamics 365 release schedule and early access?, Microsoft, October 2026
• Learn the basics of Dynamics 365 Sales, Microsoft, October 2026
• Welcome to Dynamics 365 Sales, Microsoft, October 2026
• Welcome to Dynamics 365 Customer Service, Microsoft, October 2026
• Use Word templates to create standardized documents, Microsoft, October 2026
• Application lifecycle management (ALM) basics with Microsoft Power Platform, Microsoft, October 2026
• Solution concepts with Power Platform, Microsoft, October 2026
• Create and edit columns in Dataverse using Power Apps, Microsoft, October 2026
• Odoo Documentation (19.0), Odoo, October 2026
• CRM, Odoo 19.0 documentation, Odoo, October 2026
• Standard and extended support, Odoo 19.0, Odoo, October 2026
• Upgrade, Odoo 19.0 documentation, Odoo, October 2026
• Fields and widgets, Odoo 19.0 documentation, Odoo, October 2026
• Free CRM Template (for Excel) & Guide, Salesforce, October 2025
• Brave results for crm documentation template user guide, Brave, October 2026