Feature · Custom Fields

Custom fields your admin ships without a certification track.

Fourteen field types across every object. Per-field read, write, and visibility by role. Field-level audit on every edit. Conditional required rules, dynamic defaults, validation at save time, and formula fields that walk lookup relationships three levels deep. All included, all point-and-click, all on every paid tier.

Start free trial See pricing
What custom fields are for a revenue team

The first thing every new team asks for.

Custom fields are the smallest unit of customization in a CRM and the one every team asks for inside the first week. Your business captures something the standard schema does not: a vertical attribute, a scoring input, a compliance flag, a renewal driver, a lifecycle stage with your own vocabulary. The CRM either lets you add it in a few clicks or it does not, and that choice shapes how closely your pipeline reports actually match how your team sells. The scenarios below are the ones we see on the first implementation call every time, in the same order, from teams across every industry.

Vertical attributes

Industry, segment, source captured cleanly.

Every team wants a few picklists on Account that reflect how they actually segment the book: vertical, size band, acquisition source, strategic flag, parent-company status. Picklists stay governed centrally, free-text drift stays out of the data, and reports group by the real segmentation instead of by whatever a rep typed into a notes field on a Tuesday afternoon.

Deal context

Competitor, win reason, product fit on the deal.

A deal needs more than name, amount, stage, close date. Teams add Competitor picklist, Win Reason picklist, Product Fit score, Technical Decision Maker lookup, Procurement Involvement boolean. The reporting layer picks all of them up natively, so win-rate by competitor or close-rate by product-fit score is a filter chip, not a monthly ask to the data team.

Compliance flags

KYC, consent, retention stored per record.

Regulated teams need a KYC Status picklist, a Consent Received boolean, a Retention Period date on Contact. These fields need field-level permissions so only compliance can edit them, audit history so examiners can trace every change, and validation rules so an account cannot be marked Approved without the supporting evidence being filled in first.

Lifecycle scoring

Fit, engagement, propensity live on the record.

Marketing and ops teams want numeric Fit Score and Engagement Score fields on Lead and Contact, feeding routing rules and dashboards. Scores often live as formula fields pulling from behavioral signals and firmographics, with the formula editor exposing a live preview against a real record so you can confirm the math before anyone depends on it in a flow.

Handoff metadata

Onboarding plan, kickoff date, CSM assigned.

Sales-to-delivery handoff lives on fields: Onboarding Plan picklist, Kickoff Date date, Assigned CSM lookup to user, Implementation Risk picklist. Those fields drive the Closed Won flow that creates the project, assigns the CSM, and emails the kickoff template, with no middleware step in between.

Renewal drivers

Health, usage trend, renewal risk per account.

Renewal motions depend on fields that other systems write: Product Health picklist, Usage Trend picklist, Renewal Risk picklist, Executive Sponsor lookup to Contact. Formula fields can roll trailing-ninety-day signals into a single renewal-risk indicator the CSM dashboard groups on without a BI tool in between.

Internal workflow

Approval status, review stage, blocker owner.

Internal routing uses its own fields: Approval Status picklist, Review Stage picklist, Blocker Owner lookup to user, Days In Current Stage number. These power the deal-rotting flow, the approvals queue, and the Monday pipeline review on the manager side, with no second system to maintain.

The fourteen field types Strkr ships

Every shape your real data takes.

A real custom field system needs the full type vocabulary your business uses, not a short list of text and number. Strkr ships fourteen first-class field types on every paid tier, each with the right form control, the right validation layer, the right report semantics, and the right API serialization. No type is behind a tier, no type is a bolt-on, and no type is "coming soon."

Text and rich text

Short text, long text, rich text with HTML.

Short text for names and short identifiers. Long text for notes and descriptions. Rich text for formatted content with headings, lists, inline links, and image references. Rich text ships with a character-count guard that blocks a save past the configured cap so markup inflation never surprises the storage tier.

Number and currency

Integer, decimal, currency, percent.

Integer and decimal types with configurable precision. Currency type tracks the ISO code per record, so a global pipeline mixes USD, EUR, GBP, and reports convert at the fx snapshot of each record. Percent type stores as a decimal under the hood and renders with the correct suffix across list views, detail pages, and exports.

Date and datetime

Date, datetime, with per-tenant timezone.

Date fields store the day. Datetime fields store the instant and render in the viewer's timezone with the tenant default as fallback. Flow conditions that compare dates use the tenant's calendar, so a nightly flow fires at local midnight whether your office is in Austin or in Berlin.

Boolean

True-false with meaningful labels.

Boolean fields render as a toggle with the labels you set: Approved vs Not Approved, Opted In vs Opted Out, Primary vs Not Primary. The underlying value is a simple yes-or-no, but your reps see the vocabulary of your business, not a generic checkbox that forces interpretation on every list view.

Email, phone, URL

Format-aware, click-through, searchable.

Email, phone, and URL types validate shape at save time, render as a mailto, tel, or external link on the detail page, and index for global search. Phone fields support country-code normalization. URL fields open in a new tab with a safe target. Imports catch malformed values on dry-run instead of landing them in the record.

Picklist and multi-picklist

Governed, ordered, cascading values.

Picklists hold ordered values with inactive flags, dependent cascades, and translations. Rename a value in one place and every record referencing it stays in sync. Dependent picklists let State narrow when you choose Country equals US, so your reps cannot land Texas on a Canada record. Multi-picklist captures a Technologies-In-Use set on Account: pick several values from the same governed vocabulary, group reports by one, filter by any, govern the list in one place.

User and record lookups

Point to any user or any related record.

User fields point to AE, SDR, CSM, Legal Reviewer, Procurement Owner. Pickers filter to active users by default and keep inactive users resolvable for legacy records. Record lookup fields point from one object to another: Primary Contact on Account, Parent Account on Account, Related Opportunity on Case. Lookups are indexed, cascade-aware, exposed to the formula editor, respected by the Flow engine for three-level walks, and visible in reports for cross-object filtering.

File attachment

Attach documents to a record directly.

File fields hold one or more uploads scoped to the record. Permissions follow the parent object, so a contract file inherits the account's visibility rules automatically. Downloads log to the audit trail with user and timestamp for teams that need a paper trail on who read what.

Formula and computed

Spreadsheet syntax, three-level lookups, rollups.

Formula fields compute at read time with a spreadsheet-style syntax your ops lead already reads: ROUND, IF, DATEDIFF, CONCAT, ISBLANK, TODAY. Formulas reach up to three levels of lookup, so a formula on Opportunity can read Account.Owner.Manager.Region in a single expression. Computed fields are the aggregate siblings: count of open opportunities on Account, sum of this-quarter revenue on Contact, max activity timestamp on Lead. The runtime caches both and invalidates the cache the moment any upstream field changes, so detail pages and list views stay instant without a nightly job.

Governance that keeps fields trustworthy

Permissions, audit, validation, defaults.

Adding a field is the easy part. The harder part is keeping it clean, keeping it visible to the right roles, keeping bad values out, and keeping a record of who changed what and when. Strkr ships the governance surface on every tier because without it, custom fields become a graveyard of half-filled columns inside the first quarter.

Per-field permissions

Read, write, visibility by role, per field.

A margin field on a Retainer should be visible to the GM and hidden from the junior AE. A credit-score field on a Borrower should be editable by underwriting and read-only to sales. Per-field permissions take the role matrix you already configured and tie it to the field directly, so you govern once and the UI, API, imports, exports, and reports all respect the same rule.

Field-level audit

Every edit on every field, who, when, what.

Every change on every field logs the old value, the new value, the user, the source (UI, API, import, flow), and the timestamp. Visible on the record timeline, exportable for compliance, retained for the lifetime of the record. Regulated teams get the paper trail examiners ask about without a bolt-on compliance tool.

Required rules

Required always, by status, or by condition.

A field can be always required, required only in certain stages, or required only when another field has a specific value. Stage equals Closed Won requires Win Reason filled. Status equals Approved requires KYC Date and Approver Signature filled. The rule fires server-side at save time so no client workaround lands bad data.

Dynamic defaults

Default values that respond to context.

Default values can be a literal (Status equals New), a function (Today, Current User, Current User's Manager), or a conditional expression that reads other fields on the same record. A Territory default picks the right region from the account's billing country without the rep thinking about it, and the default fires on create instead of waiting on a flow.

Validation rules

Server-side blocks with your error copy.

A rule says, "if stage equals Closed Lost and Loss Reason is empty, block the save and surface this message." Rules evaluate server-side before the write, so the same guardrail covers the UI, the API, the CSV importer, and the flow engine. One rule, one message, every entry point gets the same stop.

Field dependencies

A field appears when another field matches.

Conditional visibility hides fields until they are relevant. Loss Reason only appears when Stage equals Closed Lost. Second Interviewer only appears when Interview Stage equals Round Two. The layout stays short on the common case and expands exactly when the context demands more input, so reps see fewer fields and fill the right ones.

Picklist history

Deprecated values stay queryable.

A picklist value marked inactive stops showing in new picker selections but stays queryable on historical records and reports. A 2024 win-reason picklist can be reorganized for 2026 without rewriting the historical pipeline, and dashboards that look back twelve months do not break the first time a vocabulary change ships.

Rename-safe migrations

Rename a field without breaking formulas.

Fields have a stable internal key separate from their display label. Rename the label and every formula, report, flow, layout, and API consumer keeps resolving the same underlying field. The display label change ripples through the UI immediately, with no stale references and no cleanup pass needed afterward.

Field-level help

Help text sits next to the field itself.

Admins attach a short help string to any field. The string renders on hover in the UI, shows in the mobile app, appears in the API docs auto-generated for your tenant, and prints into the CSV import template. Reps stop asking what a field means and the admin stops being the human help text.

Honest comparisons against the three names you know

Where Strkr lands against HubSpot, Salesforce, Pipedrive.

Custom fields exist in every CRM. What differs is which types you get, who can govern them, how deep the formula engine reaches, how far field-level permissions go, how long audit history is retained, and what you pay to unlock the parts that actually keep the data trustworthy. We walk the dimensions in plain language, hold back on the slander, and let you decide. The facts below reflect the published product tiers as of this writing and are the ones that come up on every evaluation call once the team moves past the pricing-page glance into the admin surface.

HubSpot

Fields fine, formula engine is the ceiling.

HubSpot handles standard field types across its tiers and ships a calculation property for simple math. The real ceiling shows up on multi-step logic and cross-object walks: HubSpot calculation properties cannot reach fields on arbitrary related objects beyond a limited set, and conditional required logic on properties lands in paid-tier workflows rather than as a native field rule. Teams that outgrow calculation properties typically script their business logic in a middleware tool.

Salesforce

Deep engine, admin certification is the gate.

Salesforce formula fields and validation rules are the mature benchmark. The gating factor is the certified admin: formula syntax, cross-object references, roll-up summary rules, and sharing-model implications all sit comfortably inside the Salesforce Administrator certification scope. Fully loaded admin cost in the US runs into six figures per year, which is a budget line most Strkr-sized teams do not need to carry.

Pipedrive

Basic types covered, less beyond that.

Pipedrive supports standard text, number, date, picklist, and user fields on its tiers. Formula fields and conditional required logic are less developed than the HubSpot or Salesforce surfaces. Teams that need a renewal-risk computation or a role-aware required rule typically push that logic into a middleware tool or a spreadsheet rather than keeping it on the record.

Strkr

Fourteen types, three-level formulas, no admin.

Strkr ships fourteen field types on every paid tier, per-field permissions, field-level audit, conditional required rules, dynamic defaults, validation at save time, and formula fields that walk lookup relationships three levels deep. The builder is point and click with a live preview, so a revenue-ops lead ships production fields the same afternoon they decide to add them.

Who edits what

Per-field permission is table-stakes for us.

HubSpot gates field-level editing by property-level permission on Enterprise tier. Salesforce handles it via profile and permission set, which is powerful but complex. Strkr ships per-field read and write permissions on every paid tier, with the same role matrix the rest of the product uses, so the governance story has a single surface.

Audit history

Field-level audit on every record, every tier.

Salesforce tracks field history on up to twenty fields per object on standard tiers with longer-horizon retention on higher tiers. HubSpot surfaces property history on key properties on paid tiers. Strkr tracks every edit on every field with user, source, old value, new value, timestamp, retained for the lifetime of the record and surfaced on the record timeline directly.

Price trajectory

No tier jump to unlock the real governance.

The pattern across HubSpot and Salesforce is that the governance (field-level permissions, deeper audit, conditional required rules, calculated-field complexity) upgrades with the tier. Strkr includes the governance on every paid tier, so the data model does not drive the subscription math and the subscription math does not drive what your fields can enforce.

How teams actually use custom fields

Five playbooks shipped in a single week.

The best way to see what custom fields unlock is to walk a few that teams shipped recently. Five playbooks, five different business pressures, each live inside a week of starting the trial. None of them involved a certified admin, a Hub upgrade, or a middleware tool. Each one swapped a spreadsheet, a Slack thread, or a tribal-knowledge rule for a field that lives on the record and shows up correctly in every list view, every report, every flow, and every API read. The patterns below are directly transferable: the business shape changes, the mechanics do not.

Playbook one

Deal rotting by stage with field-level audit.

A mid-market sales team added a Days In Current Stage formula field on Opportunity, a Rotting Flag boolean driven by a per-stage threshold, a Last Rot Review datetime, and a per-field audit trail on Stage. The weekly deal review surfaces every rotting deal with the field history on display, so the manager sees not just the current state but the pattern of how the deal has stalled, which stage it stuck in, who last touched it, and whether a legitimate reason (a legal hold, a procurement cycle, a champion change) explains the delay. The whole motion runs off five fields and one list view, no bolt-on reporting layer.

Playbook two

KYC compliance with conditional required fields.

A regulated fintech team added a KYC Status picklist on Contact, a KYC Approved By user lookup, a KYC Approval Date date, a Supporting Documents file field, and a conditional required rule that blocks setting KYC Status equals Approved without the approver, the date, and the documents filled in. Per-field permissions keep the status field editable only by the compliance role and read-only to sales, with the audit trail capturing every state transition for the lifetime of the record. The examiner on the quarterly review gets the paper trail from the record timeline, exported with one click, without a bolt-on compliance tool and without a dedicated spreadsheet that sales has to remember to update.

Playbook three

Renewal risk with a three-level formula field.

A B2B SaaS CSM team added a Renewal Risk formula field on Account that reads Account.PrimaryContact.LastLoginDate, Account.SupportTickets.OpenCount, and Account.Opportunities.LatestStage. Three levels of lookup, one formula, one dashboard chip. The CSM sees a numeric risk score on every account without a BI integration, a nightly ETL job, or a reverse-sync from a product-analytics tool. The formula editor previewed the computation against five real accounts before the field went live, which caught an edge case (an account with no primary contact) that would have crashed the dashboard on day one. Null-safe operators handled it in one line of the formula instead of a special-case flow.

Playbook four

Role-aware layouts via field-level permissions.

An agency with sales, finance, and delivery teams on the same account layout turned on per-field permissions in a single working session: cost fields visible to finance, hidden from sales; delivery-notes field editable by delivery, read-only to sales; forecasting fields visible to sales, hidden from delivery. One record, three audiences, zero duplicate layouts, zero copy-paste of account records across silos. The API tokens the agency uses to sync accounts to their project-management tool respect the same per-field permissions, so no field a given role cannot see in the UI leaks through the integration layer either.

Playbook five

Dynamic defaults for territory routing on create.

A sales org added a Territory picklist on Lead with a dynamic default that reads the billing country and the industry picklist to pick the right region on create. The rep stops routing manually, the lead-routing flow stops needing a separate enrichment step, and the territory field is correct at the moment the record first exists rather than ten minutes later after a scheduled job catches up. Reports grouped by territory stop over-counting the Unassigned bucket, forecast math stops wobbling on new leads that have not yet been enriched, and the SDR picking up the lead sees the right territory in the record view the first time.

Fourteen field types, per-field permissions, formula fields with three-level lookups.

All included on every paid tier of Strkr. No admin certification, no Hub upgrade, no middleware. Start a free trial, ship your first production field in an afternoon, keep your current plan.

Start free trial See pricing
Common questions

What buyers ask about this feature.

How many custom fields can I create per object in Strkr?

Field counts are generous enough that most teams never hit them. The entry paid tier supports up to one hundred custom fields per standard object and fifty custom fields per custom object. Higher tiers raise or remove these caps. Formula fields and computed fields do not count against the storage tier because they do not store a value on the record. The practical result is that teams can model their real business shape on day one without planning a tier upgrade. If you anticipate running past these numbers, the Scale and Enterprise tiers are the right conversation.

Are custom fields on Strkr different from custom fields on HubSpot or Salesforce?

The surface is similar, the gating is different. HubSpot ships standard field types across tiers and layers calculation properties on top, but conditional required logic lives in paid-tier workflows and the formula engine does not walk arbitrary related objects. Salesforce ships a deep formula and validation engine but the real-world build usually waits on a certified administrator. Strkr ships fourteen field types, per-field permissions, field-level audit, conditional required rules, dynamic defaults, and formula fields with three-level lookups on every paid tier, with a point-and-click builder a revenue-ops lead can run without a certification.

Can I control which roles can see or edit a given field?

Yes, on every paid tier. Per-field permissions grant read and write by role, so a margin field on a Retainer is visible to the GM and hidden from the junior AE, and a credit-score field on a Borrower is editable by underwriting and read-only to sales. The rule applies to the UI, the API, the CSV importer, and the flow engine, so a user who cannot see a field in the UI cannot read it through the API either. The governance surface is the same role matrix used across the rest of the product, which keeps the audit story on one page.

Does Strkr audit every change to every custom field?

Yes. Every edit on every field logs the old value, the new value, the user who made the change, the source of the change (UI, API, CSV import, flow, bulk update), and the timestamp. The audit entries render on the record timeline, export for compliance review, and retain for the lifetime of the record. Regulated teams get the paper trail examiners ask about without a separate compliance tool, and the audit log works the same shape on standard fields, custom fields, standard objects, and custom objects so a SOC 2 or HIPAA review covers one surface instead of four.

How do formula fields work with lookup relationships?

Formula fields read other fields on the same record and on records reached through up to three levels of lookup. A formula on Opportunity can reach Account.Owner.Manager.Region or Account.PrimaryContact.Preferences.Timezone in a single expression. The engine walks the lookup chain, resolves the path in one query, and caches the computed value until an upstream field changes. The editor shows a live preview against a real record and against alternative sample records so you can confirm the formula handles null parents, inactive users, and other edge cases before you ship it to production.

What is the difference between custom fields and custom objects?

Custom objects define a new record type with its own schema: a Loan, a Property, a Membership, a Grant. Custom fields are the attributes that live on any record, standard or custom: Industry on Account, Fit Score on Lead, Renewal Risk on an Account, KYC Status on Contact, Loan Amount on a custom Loan object. The two features are complementary. Custom objects give you the shape. Custom fields give you the detail. Most teams add custom fields to standard objects on day one and reach for custom objects when their business shape genuinely needs a new record type the standard schema does not cover. Both ship on every paid tier.

Can I set a required rule that only fires in certain stages or conditions?

Yes. Required rules can be always required, required only in specific stages, or required only when another field has a specific value. Stage equals Closed Won requires Win Reason filled, Status equals Approved requires KYC Approver and Approval Date filled, Loss Reason only required when Stage equals Closed Lost. Rules evaluate server-side at save time, so the UI, the API, the CSV importer, and the flow engine all respect the same guardrail. The error message is yours to write, which keeps the enforcement voice consistent with the rest of your in-product copy.

Can I migrate custom fields from HubSpot or Salesforce to Strkr?

Yes. The Strkr migration tooling exports field schema and record values from HubSpot and Salesforce, maps fields with a rename and retype step, and imports records with validation preserved. Picklist values carry over with an optional remap step so a HubSpot industry vocabulary can land as the Strkr industry vocabulary without manual find-and-replace. Formula fields are recreated in the Strkr formula editor using a side-by-side preview so you can confirm each formula computes the same value on a sample record before cutting over. For teams on HubSpot Enterprise purely for property-level governance, or on Salesforce running an admin primarily for formula and validation maintenance, the migration path often pays for itself inside the first renewal cycle.

Related features

Pair this with...

Customization Custom Objects Flows Forecasting Reports

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