Every CRM starts clean and ends as a 200-field swamp because nobody owns the schema. This guide gives RevOps an opinionated process to decide which fields exist on accounts, contacts, and opportunities, which are required at each stage gate, and which drive reporting. Follow the steps in order. Trim the ones that argue for new fields and keep the ones that argue for governance, and your team will stop debating field placement in every weekly meeting.
Time: 1-2 weeks for first design, quarterly reviews after
Fields exist to serve reports, forecasts, routing rules, and stage transitions. If no downstream artifact reads a field, the field should not exist. Start by listing every pipeline report, forecast view, segmentation query, and automation your team runs today, then write down which fields each one reads. This becomes your required field list. Everything else is a candidate for deprecation. Teams that skip this step design schemas by committee and ship 40 fields nobody will fill. Teams that do this step ship 15 fields reps will actually keep up to date.
Every B2B CRM needs the same lean spine before you add anything custom. For accounts: name, domain, industry, employee count, country, owner, type (prospect, customer, partner), lifecycle stage. For contacts: first name, last name, email, phone, title, role (economic buyer, champion, user, blocker), account, owner. For opportunities: name, account, amount, close date, stage, forecast category, primary contact, product line, source. These 25 fields cover 80% of real reporting needs. Resist the urge to add vanity fields until you can prove the spine is working end to end.
Fields do different jobs and deserve different rules. Classify each proposed field into one of four buckets. Reporting fields feed dashboards and forecasts, must be high fill rate, and should be picklists wherever possible. Routing fields drive assignment and territory logic, must be populated at create time, and must be picklists. Stage-gate fields are required at specific pipeline stages, enforced by validation. Display-only fields are useful context but never read by a report or workflow, kept lean because reps have to look at them. If a field does not fit a bucket, it does not get built.
Making every important field required on create is the single fastest way to train reps to type garbage. Instead, tie required fields to the pipeline stage where the data actually needs to exist. At Qualification: primary contact, pain, budget authority. At Proposal: product line, amount, close date, decision criteria. At Negotiation: redlines status, procurement contact. At Closed Won: signed order, start date, product mix. Validation blocks the stage transition when a required field is empty, so the schema teaches reps where data belongs in the sales motion rather than nagging them on first keystroke.
Picklist drift is how clean schemas rot. Every categorical field (industry, country, lead source, stage, role, type) gets a canonical value list owned by RevOps and locked against free-text entry. New values go through a change request that proves the business reason, the report that will read it, and the deprecation plan for retired values. No 'other' bucket, because 'other' becomes 40% of your records within a year. If a rep needs a value that is not on the list, that is a signal the list needs a review, not a signal to open a text field.
Not every field needs RevOps approval, and pretending otherwise just creates a bottleneck. Draw a bright line between the shared schema (RevOps owns, cross-team reporting reads) and team-owned fields (one team uses, no cross-team report depends on it). Marketing wants a field for campaign attribution they alone will read: fine, mark it marketing-owned, keep it off the shared reporting layer. CS wants a field for health score inputs they alone will use: fine, mark it CS-owned. The rule is simple. Cross-team reporting fields need RevOps governance. Single-team display fields do not. This stops the political fights and keeps the shared schema lean.
A schema that grows is a schema. A schema that only grows is a swamp. Before you ship any new field, write the deprecation condition for it: when fill rate drops below a threshold, when the report that depends on it is retired, when the business process changes. Run a monthly deprecation sweep that reads fill rate, last-used date, and consumer count, then flags candidates. The admin wiki lists every deprecated field, when, and why, so new teammates do not reinvent the same field six months later. Teams that build the deprecation path first stay at 30 fields. Teams that do not land at 200.
Never ship schema changes directly to production. Build the proposed schema in a sandbox tenant, migrate a representative sample of records using a crosswalk from the old fields to the new ones, and dry-run the full report suite and automation pack against the migrated data. Compare report outputs before and after. If a report changes unexpectedly, the schema is wrong or the crosswalk is wrong. Only after the sandbox pass is clean do you cut over production, in waves, with a backup and a rollback plan. A schema change that breaks a VP's forecast on Monday morning is how RevOps loses change-control authority for a year.
A schema is a living contract between RevOps and every team that reads from the CRM. Publish the field inventory, classifications, owners, picklist canonicals, required-at-stage rules, and deprecation log in a single admin wiki page. Assign a RevOps owner for the shared schema and a named owner for each team-owned field. Hold a quarterly schema review with sales, marketing, and CS leadership to walk the fill-rate dashboard, the deprecation candidates, and the pending field requests. The review is the forcing function that keeps the schema honest. Skip it for two quarters and you will have another 50 orphaned fields to clean up.
For most B2B teams, a healthy shared schema lands at 15 to 25 fields on accounts, 10 to 15 on contacts, and 15 to 20 on opportunities, with team-owned custom fields layered on top. If you are past 40 shared fields on any object and the fill rate is below 60%, you have a schema problem, not a reporting problem.
Required at stage, almost always. Required-on-create fields train reps to type garbage so they can save the record and move on. Required-at-stage fields tie the data requirement to the moment in the sales motion where the field actually matters, enforced by validation that blocks the stage transition. Keep the per-stage required list to five fields or fewer so reps can realistically clear the gate.
RevOps owns the shared schema and the picklist canonicals, with a named owner per shared field. Team-owned custom fields are owned by the team that uses them, with the rule that they cannot appear in cross-team reports. A standing quarterly schema review with sales, marketing, and CS leadership approves new fields, retires old ones, and keeps the inventory honest.
Lock the field to picklist-only entry with no free-text and no 'other' escape hatch. Publish the canonical value list in the admin wiki and route new value requests through a weekly RevOps change board. Deprecate retired values with a bulk-update crosswalk, never by leaving them orphaned on historical records. Industry and Country are the two picklists worth governing on day one.
Write the deprecation condition when the field is first built, run a monthly fill-rate and consumer-count report, and flag fields below 20% fill rate or with zero report consumers. If any report ever read the field, build a crosswalk from old to new values before you archive it. Then migrate affected records in sandbox, diff the reports, and only cut over production once the diff is clean. Document every retired field so nobody rebuilds it six months later.
Strkr AI is useful for the inventory and classification pass, where it can scan existing fields, surface fill-rate anomalies, suggest deprecation candidates, and propose picklist canonicals from historical values. The RevOps owner still approves every change and the quarterly review still runs. Treat Strkr AI as the analyst that drafts the recommendation, not the decision-maker that ships it.
Strkr ships with picklist locks, required-at-stage validation, and field-level governance so RevOps can design a lean schema and keep it that way. Start free or walk the full platform.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
