Feature · Pipeline Fields

The right pipeline fields, required at the right stages.

A guide to the pipeline field catalog: the small set of core fields every deal needs, the custom fields teams add, the stage-gated required pattern that keeps data clean, and the Layouts surface that configures the whole thing without engineering.

Start free trial See pricing
The field discipline problem

Six reasons pipeline fields rot without discipline.

A pipeline field catalog that nobody respects produces the stale-data problem that erodes forecast quality and manager coaching alike. The six observations below are what Strkr customers report as the common failure modes. Each one is a discipline gap; each one is addressable with the right field design and the right Layouts configuration.

Required too early

Fields required at creation that cannot be known.

A field required at deal creation that cannot be known at creation (decision maker, budget confirmed, procurement timeline) produces garbage data as reps fill the required field with whatever gets them past the save button. The data looks clean to the reporting; the reporting is useless.

Too many required

A long required list drives data abandonment.

A deal record requiring 25 fields at creation drives reps to minimize data entry: they create the deal with the required fields filled with placeholders and never return to clean them up. The right number of required fields at creation is typically 4 to 6; everything else should be stage-gated.

No field-level governance

Reps see fields they should not.

Without field-level permissions, every rep sees every field on the deal. Compensation data, pricing floor, discount authority limit, legal review flags render to roles that should not see them. The compliance posture erodes and the sensitive data leaks to screenshots and reports.

Free text everywhere

Picklist fields slip to free text.

A field defined as free text when a picklist would fit (industry, product interest, decision timeframe) produces 50 variations of the same answer. The reporting fragments; the analytics become anecdotes. The right field type (picklist, multi-select, boolean) up front saves the cleanup project.

Fields drift from reality

The field catalog outlives its usefulness.

Fields added two years ago for a motion persist long past the motion. Reps see them, do not know what they are for, and fill them with noise or leave them blank. The pipeline field catalog needs quarterly review; dead fields need retirement.

No audit on changes

Field edits happen without accountability.

A pipeline field changed without an audit trail (close date pushed, amount reduced, stage advanced) creates the trust gap where the manager cannot tell if the rep is managing honestly. Every field change needs an audit entry; the review surface needs to show the history.

The core pipeline fields

Six fields every pipeline deal should carry.

The honest core field list is small. The six below are what Strkr customers consistently keep as required at creation; adding more required fields typically backfires. Everything beyond this list should be stage-gated or optional.

Name

A human-readable deal label.

The deal name is a human-readable label along the lines of Acme Corp 2027 Enterprise Expansion, City of Portland Fire Station Renovation, or QuickBooks Online Standard Setup. The naming convention is set by the team (owner last name plus account plus year, account plus product plus year) and renders consistently across every surface.

Amount

The expected contract value.

The deal amount is the expected contract value computed from the line items. For an annual recurring motion the amount is annual contract value (ACV); for a one-time motion the amount is total contract value (TCV). The field feeds pipeline coverage, win-rate math, and forecast weighting.

Stage

The lifecycle position.

The stage reflects where the deal is in the pipeline lifecycle. The stage transitions follow the defined entry and exit criteria; stage change triggers downstream automation and reporting. The stage default sets the probability baseline.

Close date

The expected close for the forecast.

The close date is the current expected close for the deal, updated as the deal moves. Close dates in the current forecast period roll into the forecast; the field discipline (realistic dates, updated proactively) matters for forecast quality.

Owner

The accountable AE.

The owner is the single accountable AE for the deal. Supporting roles attach to the team roster but the owner is unambiguous. Ownership drives the comp calculation and the manager coaching assignment.

Account

The customer the deal is with.

The account is the customer the deal is with. Every deal rolls up to exactly one account; the account carries the ongoing relationship. The field is required because the deal cannot be reported, forecasted, or routed without the account association.

The custom field patterns teams add

Six common custom fields with the design right.

Beyond the core, teams add custom fields that match the motion. The six patterns below are the ones most Strkr customers add in the first month. Each pattern has a design choice (field type, picklist values, required state) that separates a field that works from a field that rots.

Decision maker

A contact lookup, stage-gated required.

The decision maker field is a contact lookup (not free text), stage-gated required (not required at creation, required at Negotiation). The rep identifies the decision maker during Discovery and populates the field by the time the deal advances to Negotiation; the required-at-stage enforcement keeps the data clean.

Lost reason

A picklist on Closed-Lost deals.

The lost reason is a picklist with 6 to 10 values (lost to competitor, lost on price, project canceled, no decision, no response, timing wrong, qualification error) required on Closed-Lost transitions. The picklist constrains the data; the quarterly review runs clean against the finite values.

Lead source

A picklist populated at lead conversion.

The lead source field is a picklist populated at lead conversion from the originating lead attribution. The field feeds marketing reporting (pipeline and revenue by source) and does not require ongoing rep maintenance; the lead conversion workflow sets it once at deal creation.

Deal type

A picklist that drives routing.

The deal type is a picklist (new logo, expansion, renewal, win-back) that drives routing (expansion deals go to the account AE, renewals go to CS or renewals team), forecasting (new logo versus expansion math), and reporting (motion mix). The three to five values cover most motions.

Competitor

A multi-select on competitive deals.

The competitor field is a multi-select picklist (named competitors in your category) populated during Discovery when competitive pressure is identified. The field feeds competitive reporting (win rate by competitor, discount pressure by competitor) and informs the enablement team.

Legal review status

A picklist with field-level visibility.

The legal review status is a picklist (not required, pending, in review, approved, blocked) visible only to specific roles (deal desk, legal, specific sales management levels) under field-level permissions. The rep sees the pending or approved value without seeing the internal legal notes.

What Strkr delivers for pipeline fields

Six capabilities that make field configuration work.

Strkr ships the field configuration surface through the Layouts feature and the custom field admin. The six capabilities below are what makes the field catalog maintainable at scale. All six ship inside the standard Strkr seat.

Custom field admin

14 field types including user and lookup.

The custom field admin supports 14 field types: text, long text, number, currency, date, datetime, boolean, picklist, multi-select picklist, user lookup, record lookup, URL, email, phone. The RevOps lead adds and configures fields through the admin surface without engineering.

Stage-gated required

Required at the stage that needs the data.

The required state is configurable per stage. The decision maker field is not required at creation but is required to advance to Negotiation. The implementation plan field is not required to advance to Negotiation but is required to advance to Closed-Won. The stage-gated pattern enforces discipline without blocking early-stage deal creation.

Field-level permissions

Visibility per role on sensitive fields.

Field-level permissions ship through the Layouts Phase 1 feature set. Sensitive fields (legal review status, pricing floor, discount authority, compensation data) render only to the roles that should see them; other roles see the field as hidden rather than seeing a redacted value.

Layouts per team

Field groups and visibility per team.

The Layouts feature configures the field catalog per team: which fields render, which section they live in, which are required, which are read-only. Enterprise teams see the enterprise fields; SMB teams see a leaner surface. The configuration ships without engineering.

Audit on every field

Change history visible inline.

Every field change on the deal lands in the audit trail inline on the record. The rep sees who changed the close date, when, and from what to what. Compliance reviews walk the record audit without pulling a separate report; the transparency builds team trust in the pipeline numbers.

Field retirement

Deprecated fields hide without breaking reports.

A field no longer in use can be deprecated through the admin: hidden from the record UI, preserved on historical records for reporting back-compatibility, flagged in the field catalog for eventual archival. The quarterly field review cleanly retires dead fields without breaking historical reporting.

The right pipeline fields, required at the right stages.

Strkr Layouts configure the field catalog per team with stage-gated required rules, field-level permissions, and the audit trail compliance needs. Start a trial and shape the deal record to the real motion in the first week.

Explore layouts Start free
Common questions

What buyers ask about this feature.

What pipeline fields should every deal record carry?

The honest core list is small. Six fields should be required at creation: name (a human-readable label), amount (the expected contract value), stage (the lifecycle position), close date (the expected close for the current forecast), owner (the accountable AE), and account (the customer the deal is with). Beyond this core, custom fields are stage-gated required (required to advance to specific stages) rather than required at creation. The reason the core list is short is that a required field at creation has to be answerable at creation; requiring the decision maker at creation when the rep has not yet identified the decision maker produces garbage data. The core six are answerable at creation for every deal.

What is stage-gated required and why does it work?

Stage-gated required is the pattern of requiring a field for stage advancement rather than for deal creation. The decision maker field is not required at creation but is required to advance to Negotiation. The implementation plan field is not required at Negotiation but is required at Closed-Won. The pattern works because it aligns the required state with when the data can realistically be known: the rep is expected to identify the decision maker during Discovery and populate the field by Negotiation. The enforcement happens at stage transition, which is a natural intervention point for the rep. Required at creation produces garbage data for fields that cannot be known at creation; stage-gated required produces clean data.

What custom fields do most pipeline teams add?

Six common custom field patterns cover most pipeline motions. Decision maker (contact lookup, stage-gated required at Negotiation). Lost reason (picklist with 6 to 10 values, required on Closed-Lost). Lead source (picklist populated at lead conversion from the originating attribution). Deal type (picklist: new logo, expansion, renewal, win-back, drives routing and forecasting). Competitor (multi-select picklist of named competitors, populated during Discovery). Legal review status (picklist with field-level visibility to deal desk and legal roles only). Each one has a design choice (field type, picklist values, required state) that separates a working field from one that rots. The right configuration up front saves the cleanup project later.

How do field-level permissions work in Strkr?

Field-level permissions ship through the Layouts Phase 1 feature set. Sensitive fields (legal review status, pricing floor, discount authority, compensation data, PII) render only to the roles that should see them; other roles see the field as hidden rather than seeing a redacted value. The permission model respects the actor on both the UI and the API, so a rep querying the deal through the REST API cannot see fields they are not entitled to see on the record detail page. The configuration ships through the Layouts admin surface; the RevOps lead configures field visibility per role per layout without engineering. The audit log captures field access and field changes with the actor identity so compliance reviews can walk the history for any sensitive field.

How often should the pipeline field catalog be reviewed?

The common cadence is quarterly, usually at the start of the quarter alongside the sales motion review. The review covers three questions. First, which fields are not being used (less than 10 percent populated on new deals, less than 5 percent populated on advancing deals) and should be deprecated. Second, which fields are producing garbage data (free text where a picklist would fit, picklists with values that have accumulated beyond the intended set) and need redesign. Third, which new fields the motion needs (new product mix, new competitor, new deal type, new regulatory requirement) and should be added. The quarterly review keeps the catalog clean; without the review the catalog accumulates dead fields and garbage data over 18 to 24 months.

Can field changes be audited for compliance?

Yes. Every field change on the deal lands in the Strkr audit log with the actor identity, the timestamp, the old value, and the new value. The record detail page shows the audit trail inline so a manager reviewing the deal sees the field history without pulling a separate report. The log is immutable; no actor including a tenant admin can modify or delete an entry. Export is available by API or scheduled report for external compliance review. For regulated workloads (healthcare, financial services, government-adjacent), the retention policy configures to meet the compliance framework (7 years for HIPAA and SOX contexts, longer for regulated financial services). The audit trail satisfies the standard compliance requirement that automated and human actions on sensitive data be reviewable.

Related features

Pair this with...

Pipeline Deals Pipeline Deals CRM Pipeline Management Opportunity Pipeline CRM Pipeline Stages CRM Pipeline Management Account Management Custom CRM Fields

Try it free. Bring your team next week.

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.

Start free trial See pricing