How Strkr's custom objects actually work

Custom objects are the single most important CRM capability most teams undervalue when buying and regret in year two. The ability to define your own data model (new object types, their fields, their relationships) is what separates a CRM that fits your business from one you contort your business to fit into.

This post is a product tour of how custom objects work in Strkr: what you can define, how fields and lookups behave, how permissions scope, and the workflows teams actually build with them in the first week.

The design target

Strkr’s custom objects were designed around three principles:

1. Available on every paid tier. Not gated behind Enterprise. Custom objects are table-stakes CRM capability, not a premium feature.
2. Any paid user can create them. No admin certification required. If you can create a custom field, you can create a custom object.
3. First-class citizens in the data model. Custom objects work with the same formula engine, flow builder, reporting layer, and permissions model as standard objects (Accounts, Contacts, Deals, Leads).

The practical outcome: a sales ops lead at Series A should be able to extend the data model as the business evolves, without filing a ticket or buying a tier upgrade.

What a custom object is

A custom object is a new type of record you define in your tenant. It has an API name (used in formulas and the flow builder), a label (what users see), a plural label (for list views), an icon, and a set of fields.

Concrete examples teams commonly build:

• Policy (insurance agency): one record per client-policy combination. Fields: policy number, carrier, coverage amount, premium, renewal date, status.
• Project (consulting firm): one record per engagement. Fields: scope hours, delivery lead, billing cadence, start date, status, lookup to Account.
• Subscription (SaaS): one record per customer-tier-term. Fields: MRR, ARR, term length, renewal date, lookup to Account.
• Listing (real estate): one record per property. Fields: address, price, status, agent, lookup to Account (seller).
• Feature Request (SaaS product team): one record per request. Fields: title, description, votes, status, lookup to Contact (submitter) and Account.

None of these fit cleanly into standard objects. Each needs its own fields, its own lifecycle, its own reports, and its own automation triggers.

The field types

Strkr supports 14 field types on custom objects (same as standard objects):

1. Text (short)
2. Long text (unlimited, rich-text optional)
3. Number (integer or decimal)
4. Currency (number plus currency code)
5. Percent (number formatted as %)
6. Date
7. Datetime
8. Checkbox (boolean)
9. Picklist (single-select from defined options)
10. Multipicklist (multi-select)
11. Email
12. Phone
13. URL
14. Lookup (relationship to another object)

Plus two meta types that compose with the above:

15. Formula (any of the types above, computed from other fields via the formula engine)
16. Rollup (summary of child records: sum, count, min, max, avg)

Each field has its own permissions (who can read, who can write), its own validation rules (required, format, range), and its own default value.

Lookups: relationships that work

Lookups are the field type that makes custom objects first-class. A lookup from your custom object to another object (standard or custom) creates a bidirectional relationship.

For example, a Policy lookup to Account creates:

• A field on Policy pointing to the Account record
• A related list on the Account page showing all Policies for that account
• The ability to reference Account fields from Policy formulas (policy.account.industry, up to three levels deep)
• The ability to filter and report on Policies by Account fields

Lookups work across standard and custom objects in any combination. A custom Subscription object can lookup to a standard Account. A standard Deal object can lookup to a custom Project. The CRM’s data model becomes whatever shape your business needs.

Formulas on custom objects

Every custom object field can be a formula field. The formula engine supports 30+ functions (IF, CASE, AND, OR, CONCAT, DATEDIFF, FIND, MID, SUBSTITUTE, ROUND, FLOOR, CEIL, MOD, YEAR, MONTH, DAY, HOUR, WEEKDAY, and the full math library), plus cross-object references via lookups.

Concrete examples:

• project.days_until_due = DATEDIFF(TODAY(), project.due_date, 'days') automatically computed, updates every day
• subscription.health_label = IF(subscription.mrr > 10000, "key account", IF(subscription.mrr > 1000, "standard", "small")) picklist-shaped formula
• policy.carrier_name = policy.account.preferred_carrier cross-object reference via lookup
• issue.priority_score = (issue.severity * 10) + (issue.customer_impact * 5) numeric computation

Formula fields recompute automatically whenever an upstream field changes. No manual recalculation. No scheduled job. The dependency graph is managed by the formula engine.

Permissions on custom objects

Custom objects use the same permissions model as standard objects. Three layers:

1. Object-level permissions. Who can read, create, edit, delete records of this object type. Set per role.
2. Field-level permissions. Who can read vs edit each field. For sensitive fields (compensation, SSN, pricing details), restrict to specific roles.
3. Record-level permissions. Record owner, record sharing rules, conditional visibility based on field values. For example, “sales reps only see Deals they own; sales managers see all Deals for their team.”

The permissions model is identical across standard and custom objects. If you understand how it works for Accounts, you understand how it works for your custom Policy or Project object.

Custom objects in the flow builder

Custom objects fire the same trigger shapes as standard objects: created, updated, specific field changed, deleted. Flow actions can create, update, or delete custom records.

Example workflow a Strkr customer typically builds in their first week:

Scenario: An insurance agency wants to automatically track policy renewals and notify the account owner 60 days before each renewal.

• Trigger: scheduled flow runs daily at 7am
• Action 1: query Policy records where renewal_date is 60 days from today
• Action 2 (per matching record):
  • Create a Renewal Task record linked to the Policy and the Account
  • Set task.due_date = policy.renewal_date - 30 days
  • Assign the task to policy.account.owner
  • Send an email notification to the account owner

One flow, one builder, no connector. The Policy custom object, the Renewal Task custom object, and the standard Account object all work together because they share the same data model.

Custom objects in reports

Reports on custom objects work the same as reports on standard objects. You pick the object as the primary record, select fields to display, add filters, group, aggregate, and chart. Custom object reports can join to standard objects via lookups.

Example reports teams build:

• Policies by renewal month, grouped by account tier. Primary: Policy. Join: Account. Group by: policy.renewal_date (month), account.tier.
• Open Feature Requests by vote count, grouped by product area. Primary: Feature Request. Group by: product_area. Sort by: vote_count descending.
• Subscriptions at risk this quarter. Primary: Subscription. Filter: subscription.health_label = “at_risk” AND subscription.renewal_date in next 90 days.

Reports are formula-powered, which means you can compute custom metrics (conversion rates, ratios, period-over-period changes) in the report itself without pre-computed fields.

How to create a custom object

Three clicks:

1. Navigate to Admin → Objects → New Object.
2. Enter the API name, label, plural label, icon, and color.
3. Add fields using the field type picker. Save.

The object is now available in the record creation menu, list views, flow triggers, report builder, and formula engine. No deployment, no admin certification, no consulting partner.

For context on what this looks like in competitor products: HubSpot gates custom objects behind Enterprise tier, Salesforce supports custom objects from Professional but with increasing limits by tier. Strkr includes custom objects on every paid tier at no gated-feature upcharge.

When custom objects are the wrong tool

Three cases where another approach fits better:

1. The data belongs on an existing object. If what you want is a few new fields on the Account record, use custom fields on Account. Do not create a parallel object for data that already has a home.
2. The data is transactional and short-lived. Flow variables and queue tables handle short-lived state better than custom records that accumulate forever.
3. The data is content, not records. Documents, pages, and content live in the Docs module. Do not force content into a custom object.

For actual business entities (Policy, Project, Subscription, Listing, Feature Request, Milestone, etc.), custom objects are the right answer.

How to try it

Custom objects are included on every paid Strkr tier at no gated-feature upcharge. The 14-day free trial covers the full feature so you can build a real custom object end-to-end against sample data before any charge. See strkr.io/pricing.

Related reading: CRM with custom objects: what they unlock and why most teams need them covers the broader question of why custom objects matter, and How Strkr’s no-code flow builder actually works covers the automation surface that makes custom objects first-class citizens.