Build a new object in Strkr in minutes, not quarters. Field types, lookup relationships, formula fields, validation rules, picklist values, layouts. All first-class, all included, no admin certification required, no Enterprise paywall.
What custom objects actually unlock for revenue teams
When contacts, accounts, and deals are not enough.
Every CRM ships with the same four or five standard objects: leads, contacts, accounts, deals, maybe activities. For a lot of businesses those shapes cover the whole revenue motion. For a lot of other businesses they cover roughly sixty percent of it, and the remaining forty percent gets jammed into a spreadsheet, a Notion database, a backend table nobody in sales can see, or a free-text custom field on the account record. Custom objects fix that gap. They let your real business shape live inside the system of record so reports, flows, permissions, and reporting line up with how the team actually works. The scenarios below are not hypothetical. They are the real patterns we see on the first conversation with teams who outgrew contacts and deals.
Property management
Units, leases, inspections live as objects.
A single account owns ten commercial properties. Each property has twelve units. Each unit has a lease, a tenant contact, an inspection history, a maintenance ticket queue, and a rolling rent-roll amount. None of that fits into standard deal and contact fields without ugly hacks. A Units custom object with lookups up to Property and across to Contact lets the team run the real motion inside the CRM, with reports grouped by property, filtered by occupancy, and ranked by trailing-twelve-month revenue.
Membership orgs
Members, dues, chapters, events as records.
Associations and non-profits run on membership tiers, dues cycles, chapter affiliations, event registrations, and board-service history. A Membership custom object linked to Contact plus Chapter plus Dues plus Event Registration models the full relationship cleanly. Standard deal pipelines never fit this motion because membership is not a one-time close, it is a renewing commitment with activity levels, giving levels, and committee roles. Custom objects let the whole thing live where staff already work instead of in a parallel database system.
Loan servicing
Loans, payments, delinquency as linked records.
A loan is not a one-time deal. It is an opened record with a thirty-year lifecycle: origination, servicing, payment history, delinquency flags, modification requests, payoff events. A Loans custom object with child Payments and Delinquency Events gives the servicing team a system of record that holds the real timeline instead of flattening it onto an account. Underwriting, servicing, and collections each get the layout and the field-level access they need, with the audit trail that regulators ask about every exam cycle.
Agency retainers
Retainers, scopes, deliverables under one account.
An agency account holds three active retainers. Each retainer has a monthly scope, a deliverables backlog, a hours-used counter, a budget cap, a renewal anniversary, a point-of-contact override. None of that fits in the opportunity object which is designed for one-time close motions. A Retainer custom object linked to Account plus Deliverable plus Monthly Scope solves it in an afternoon, and gives the GM a profit-margin formula field that pulls hours used against hours billed in real time without a BI tool.
Education
Students, programs, cohorts, enrollments.
Private schools, bootcamps, and continuing-ed providers all share the same data shape: a student links to one or more programs, cohorts have start and end dates, enrollments carry status plus payment plus completion, certificates issue on completion. Standard CRM shapes bend badly against this because a student is not a contact in the sales sense and a program is not a product in the catalog sense. Students plus Enrollments plus Cohorts plus Certificates as first-class objects make the motion legible to admissions, instructors, and finance in one view that stays in sync automatically.
Grants and funding
Grants, applications, awards, reporting cycles.
A grants org tracks hundreds of outbound applications and inbound requests. Each has a sponsor, a deadline, an award amount, a reporting cycle, a status pipeline that looks nothing like a sales pipeline. A Grants custom object with its own stages and its own linked Application Documents lets the development team run alongside sales without colliding with the deal pipeline, and gives finance a clean rollup for board-reporting cycles that today lives in a quarterly spreadsheet nobody wants to maintain.
Clinical trials
Sites, protocols, enrollments, visits.
CROs and clinical teams coordinate dozens of sites, hundreds of enrolled patients, thousands of scheduled visits. Site plus Protocol plus Enrollment plus Visit custom objects, each with their own fields and their own permissions, let the team manage the operational layer that no sales-CRM out-of-the-box object will cover. Permissions on each object stay airtight thanks to field-level access, record-type routing per study phase, and validation rules that refuse a visit record missing a signed consent reference.
Lending platforms
Borrowers, applications, underwriting notes.
Alternative lenders handle borrowers who look like contacts, applications that look like deals, and underwriting decisions that look like neither. Underwriting Decision becomes its own custom object with the credit-score field, the risk-tier picklist, the signed-off-by lookup to a user, and a validation rule that blocks a Yes without a signed PDF attached. The whole underwriting history for a borrower lives on their contact record as a related list, which is exactly what the credit committee wants to see.
How Strkr custom objects work
The field types, relationships, and rules you expect.
A real custom object system is more than a table of key-value fields. It needs the full modeling vocabulary: typed fields, lookups one-to-many and many-to-many, formula fields that compute at read time, validation rules that reject bad input at write time, picklists that stay governed, layouts that control who sees what. Strkr ships every one of those on every paid tier, with the same builder sales ops uses for everything else. No admin certification, no Apex, no Hub upgrade, no SOQL. The whole surface is point and click, with a formula editor that reads like a spreadsheet.
Fourteen field types
Text, number, currency, date, user, lookup, more.
Short text, long text, rich text, number, decimal, currency, date, datetime, boolean, email, phone, URL, user, picklist, multi-picklist, lookup. Pick a type when you add a field, change your mind later with a safe migration path that preserves existing records. The same FieldTypePicker used across CRM and Projects, so your admins only learn the vocabulary once and your users see the same field patterns everywhere in the product.
Lookup relationships
One-to-many and many-to-many as first-class.
A lookup field points from any object to any other object: a Unit points to a Property, a Loan points to a Borrower, a Retainer points to an Account. Many-to-many relationships use a junction object you spin up in the same builder. Lookups are indexed, cascade-aware, and respected by the Flow engine, the report engine, and the permission layer.
Formula fields
Spreadsheet syntax, computed at read time.
Need profit margin on a Retainer: hours_used times rate minus cost. Need days until renewal: today minus renewal_date. Formula fields compute on read, never go stale, never fall out of sync with the source rows. The formula editor shows live preview against a real record so you catch a typo before it ships.
Validation rules
Reject bad input at save time, with your error copy.
A rule says "if stage equals Closed Won and amount is empty, block the save and show this message." Rules fire server-side before the write, so no amount of frontend tampering gets around them. Writable from a form, an import, an API call, or a flow, every entry point gets the same guardrail.
Picklist governance
Values live in one place, change in one place.
Picklists are governed centrally with ordered values, inactive flags, and dependent cascades (choosing Country equals US narrows State to US states). Rename a value and every record that references it updates in place. No orphaned strings, no "West Coast" vs "west-coast" drift, no cleanup job six months later.
Layout customization
Different fields visible to different roles.
The same custom object can present a sales layout, a finance layout, and a service layout, each with its own field order, section grouping, required-field set, and related-list visibility. Layouts are assigned by role, so a rep sees commercial fields and an operations lead sees internal fields on the same record.
Field-level permissions
Not every role sees every field.
A margin field on a Retainer should be visible to the GM, hidden from the junior AE. A credit-score field on a Borrower should be editable by underwriting, read-only to sales. Field-level permissions on custom objects follow the same role matrix that governs the rest of the system. No separate ACL tool, no bespoke middleware.
Record-type routing
Same object, different flavors.
A Loans object might cover residential, commercial, and SBA. Record types let one object split into three flavors with different layouts, different required fields, and different picklist slices, without three separate tables. Reports can filter by record type, and permissions can be scoped per type, so an SBA specialist sees the SBA layout and nothing else while a generalist sees the full universe.
Audit trail
Every edit on every field, who, when, what.
Changes to custom-object records log the field, the old value, the new value, the user, and the timestamp. Visible on the record timeline, exportable for compliance, retained for the lifetime of the record. Underwriting teams, regulated lenders, and clinical operators get the paper trail they need without a bolt-on compliance tool, and the audit log works the same shape as the audit log on standard objects so SOC 2 and HIPAA reviews cover one surface instead of two.
What makes Strkr custom objects different
Honest comparisons against the three names you know.
Custom objects are not new. The question is who gates them, who can build them, and what it costs to actually ship one. The three CRMs most teams compare against sit in very different places on each dimension. We will not slander anyone. We will walk the dimensions, state the facts, and let you decide.
Tier gating
Strkr: every paid tier. HubSpot: Enterprise only.
Strkr custom objects ship on every paid tier starting from the entry plan. HubSpot gates custom objects at the Enterprise tier of Sales Hub, Service Hub, or Marketing Hub, which lands roughly four times the price of the Pro tier before per-seat math. Pipedrive does not offer custom objects on any tier.
Who can build one
Strkr: ops lead. Salesforce: certified admin.
Strkr custom objects are built in a point-and-click builder by whoever owns revenue ops, no certification required. Salesforce ships custom objects on every tier too, but the real-world build usually waits on a certified admin whose fully loaded cost in the US runs into six figures a year. HubSpot requires a developer or a solutions partner for the schema-API step.
Time to first object
Strkr: an afternoon. The others: a planning cycle.
The fastest Strkr custom object our team has shipped went live in roughly forty minutes: object plus eight fields plus two lookups plus a validation rule plus a layout plus a basic report. The same object in a Salesforce org usually involves a sandbox, a change set, a QA pass, and a release window. The gap is not technical. It is governance overhead.
Flow and automation
Strkr: custom objects fire the same triggers.
A record_created or record_updated event on a Strkr custom object fires the same Flow triggers as a Deal or a Contact. The flow engine does not care whether the object is built in or built by you. HubSpot workflows cover custom objects only on Enterprise tier. Pipedrive automations do not reach custom objects because there are no custom objects to reach.
Reporting
Strkr: custom objects report natively.
Reports and dashboards in Strkr query custom objects with the same filter builder and the same aggregations used on standard objects. Group by any field, filter across lookups, chart totals and averages. No separate BI tool required, no "export to CSV then build a Google Sheet" dance that marketing teams fall into when native reporting cannot see their data.
API access
Strkr: custom objects on the same REST surface.
The same REST API that reads and writes Contacts and Accounts reads and writes custom objects. Filter, sort, pageinate, batch, upsert. No separate schema API, no SOQL variant, no custom-object-only authentication layer. Integrations treat your custom objects as first-class citizens, which they are.
Permissions
Strkr: custom objects on the same role matrix.
Custom objects obey the same permission model as every other object: role-based read, create, edit, delete at the object level, plus field-level permissions, plus layout scoping. One admin surface, one audit log, one claims structure. No bespoke permission tool just because the object is custom.
Price trajectory
Strkr: no tier jump to get them.
Add a custom object in HubSpot, you move to Enterprise. Add one in Salesforce, you have added an admin. Add one in Strkr, you kept your plan and your headcount. The whole point of including custom objects on every paid tier is that your data model should not drive your subscription math, and your subscription math should not drive the shape of your business.
Middleware tax
Strkr: no Zapier, no reverse-ETL to bolt them on.
Teams that cannot get custom objects in their CRM end up syncing from Airtable, a Postgres instance, or Notion into their CRM via middleware. Every sync adds a lag, a failure mode, a line item. Strkr avoids the whole category because the custom object lives inside the CRM to begin with. Middleware exists; we just do not need it here.
Beyond the basics
Flows, reports, mobile, API, bulk ops.
A custom object only pays off when the rest of the system treats it like a real citizen. On Strkr, every surface that works on standard objects works on custom objects: automations, reports, mobile, APIs, bulk operations, exports, imports. Nothing has an "unless it is a custom object" asterisk.
Flows on custom data
Triggers, conditions, actions all included.
Loop over a custom object, query it with the same filter AST as deals or contacts, fire record_created and record_updated triggers on it, write back to it. The automation builder uses the same visual canvas and the same block library. If you learned Strkr Flows on standard objects, you already know how to automate custom objects. Scheduled flows can walk a list of custom records nightly and raise flags, send messages, or create tasks the moment a condition fires, with full dry-run previews before you ever publish.
Reports on custom data
Group, filter, chart like any other object.
Build a report on Loans grouped by status with sum of principal. Add a filter for delinquency flag. Chart it in a dashboard. Share the dashboard with the servicing team. The report builder has no concept of "this is a custom object" vs "this is a standard object," it just reads schema. Cross-object joins through lookup fields work exactly the same, so a report on Loans filtered by Borrower territory is one filter chip, not a separate ETL job.
Mobile
Custom objects render on iOS and Android.
Native mobile apps pick up custom objects from the schema and render them with your layout, your field types, your related lists. Reps in the field can create records, edit fields, run searches, and attach files on custom objects the same way they do on standard objects.
REST API
Same endpoints, same auth, same shape.
POST /objects/loans. GET /objects/loans/:id. PATCH /objects/loans/:id. The REST API treats custom objects like built-in objects. OpenAPI schema regenerates when you add a field. Integrations with Postman, custom scripts, or internal tooling do not need special-case code for custom objects. API tokens respect field-level permissions, so a token scoped to the servicing role cannot read fields the servicing role cannot read in the UI.
Bulk operations
Import, export, bulk update, bulk delete.
CSV import with column mapping, dry-run preview, and automatic validation against your custom-object field types. CSV export with filters and column selection. Bulk update on a filtered selection. Bulk delete gated by role. The whole bulk toolkit works on custom objects on day one, including the lookup-by-external-ID import mode that stitches related records together on first upload instead of forcing two passes.
Webhooks
Outbound events on custom-object changes.
Register an outbound webhook on object_created, object_updated, or object_deleted events. Payload includes the full record and the delta, signed with HMAC, retries on 5xx. External systems that need to react to a new Loan or Unit get a native integration point, not a polling job that drags on API quota and ends up out of sync whenever something hiccups.
Global search
Custom-object records show up in the omni-bar.
Hit Ctrl+K. Type a loan number. Strkr returns matching custom-object records alongside contacts, accounts, and deals. Indexing picks up new fields automatically. Reps do not have to switch tabs or know which object type they are looking for, and the ranked results blend naturally so the right record is usually one keystroke away.
List views
Saved filters and shared views per object.
Every custom object gets the same list view surface as a standard object: column customization, saved filters, shared views by role or team, inline edit, bulk select. The ops team can publish "Delinquent loans this week" or "Retainers due for renewal" as a shared view with one click.
A few real-world scenarios
Three teams, three shapes, same afternoon build.
The best way to see what custom objects can carry is to look at teams who shipped one recently. Three scenarios, three different business shapes, each built by an operations lead in a single working session.
Scenario one: boutique agency
Retainer plus Deliverable plus Monthly Scope.
A fifteen-person agency moved off a Google Sheet retainer tracker in one afternoon. Retainer object lookups to Account and Primary Contact. Deliverable child object with status, hours estimated, hours actual, due date. Monthly Scope child with hours cap and spillover rule. A formula field on Retainer rolls up hours used across the month, a validation rule blocks a Save when projected overage exceeds twenty percent without a note. Weekly flows raise a Slack ping to the account lead when a retainer crosses eighty percent of its monthly budget before the second Friday.
Scenario two: alternative lender
Borrower plus Loan plus Payment plus Delinquency.
A boutique lender replaced three spreadsheets and a Notion database with four Strkr custom objects. Borrower lookups to Contact. Loan lookups to Borrower with record types for residential, commercial, SBA. Payment child on Loan with amount, received date, applied date. Delinquency Event child with flag type, severity, resolved flag. A flow fires nightly on Loans that have missed a payment and raises a Delinquency Event automatically. The servicing team runs their whole queue off a shared list view instead of waiting on a weekly spreadsheet refresh from the finance team.
Scenario three: continuing-ed provider
Student plus Cohort plus Enrollment plus Certificate.
A continuing-education provider replaced a bespoke LMS admin panel with Strkr custom objects. Student lookups to Contact. Cohort has start date, end date, instructor, capacity. Enrollment is the many-to-many link with status, payment status, completion date. Certificate child records are generated on completion by a Flow. Reports surface completion rate by cohort and enrollment pipeline for admissions. The instructor layout hides the payment-status field, the finance layout highlights it, same record and same object with role-aware views.
Pattern across all three
Ops lead, one afternoon, zero code.
In all three cases the build was done by a revenue-ops lead or a founding operator, not by a developer. No change set, no sandbox, no release window. The data model was adjusted a few times in the first week as the team learned what they really needed, with safe field migrations in place. No one had to write a schema migration or open a ticket with engineering. The ability to iterate on the shape of the data in days instead of quarters is often the real difference between adopting custom objects and abandoning the project.
What the alternatives would have been
Hub upgrade, admin hire, or stay on sheets.
For each team the realistic alternatives were: upgrade a HubSpot plan to Enterprise, hire a Salesforce admin, or keep running the operation on a sheet with no automation, no reports, and no permissions. Strkr custom objects let them keep their plan, keep their headcount, and get a system of record their whole operation can trust and audit.
Where it goes from here
Automations, exports, integrations compound.
The first custom object is the hard one, because the shape is new. The second and third come fast because the pattern is set. Teams who ship one custom object typically ship four more within the quarter: a renewals object, a product-usage snapshot object, a case notes object, a referral partners object. Each one closes a spreadsheet or a parallel database the operations team was tending by hand, and each one makes the whole CRM a more accurate reflection of how the real business runs.
Custom objects on every paid tier, no admin required.
Build a new object in minutes, not quarters. Field types, lookups, formula fields, validation rules, workflow triggers all first-class on your custom data. Start a free trial, build your first custom object in an afternoon, keep your current tier.
What tier do I need to get custom objects in Strkr?
Custom objects are included on every paid tier of Strkr, starting from the entry plan. That is the main structural difference from HubSpot, which gates custom objects behind the Enterprise tier of its Hubs. Pipedrive does not currently offer custom objects on any tier. Salesforce includes custom objects on every tier but typically requires a certified admin to build and maintain them, which is a cost line that often exceeds the full Strkr subscription. The practical effect is that a team evaluating Strkr can plan the data model around their real business shape on day one without planning a tier upgrade or an admin hire.
Do I need a certified admin or a developer to build a Strkr custom object?
No. The custom object builder is point and click. Add fields with the FieldTypePicker, define lookup relationships with a visual picker, write formula fields with a spreadsheet-style editor that shows a live preview, set validation rules with a condition builder. No code, no SOQL, no Apex, no schema API work. A revenue-ops lead can ship a production custom object in a single working session. The limiting factor is almost never the tool but whether the operations function has been given the time to think through the data model. For teams coming off Salesforce, this is usually the first thing people comment on in the second week: the whole admin surface collapses from a certification track into a Thursday afternoon.
How do custom objects work with workflow automation and reports?
Custom objects are first-class citizens across every other Strkr surface. Flow triggers, conditions, and actions all work on custom objects the same way they work on standard objects, which means a record_created event on your Loans object can fire exactly the same action library as a record_created event on a Deal. Reports and dashboards query custom objects with the same filter builder and aggregation layer, so a trailing-twelve-month revenue chart on a Retainer object is one report, not a BI integration. The REST API exposes custom objects on the same shape as built-in objects. Mobile apps render them automatically. Global search indexes them. There is no "custom objects are second-class" asterisk anywhere in the product.
What relationship types are supported between objects?
Lookup fields define one-to-many relationships: a Unit points to a Property, a Payment points to a Loan. Many-to-many relationships use a junction object built in the same tool, so a Student can be linked to many Cohorts and each Cohort can hold many Students via an Enrollment junction that carries its own fields (status, payment, completion date). Lookups are indexed for performance, respected by the Flow engine for related-record walking, visible to the report builder for cross-object filtering, and exposed on the API for nested reads. Cascade behavior on the parent side is configurable: delete-restrict, nullify, or cascade-delete, with the right default for your data integrity needs.
Can I migrate from HubSpot custom objects or Salesforce custom objects to Strkr?
Yes. The Strkr migration tooling supports exporting custom object schema and records from HubSpot and Salesforce, mapping fields with a rename and retype step, and importing records with validation preserved. Lookup relationships are reconstructed on the Strkr side using external IDs that carry over from the source system. Formula fields are recreated in the Strkr formula editor using the mapping guide, with 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 the HubSpot Enterprise tier purely to access custom objects, this migration path often pays for itself in the first renewal cycle. For teams on Salesforce running a certified admin primarily to maintain custom objects, the savings compound from month one.
What are the limits on fields, records, and objects?
Strkr tier limits on custom objects are generous enough that most teams never hit them. The entry paid tier supports up to twenty custom objects with up to fifty fields each. Higher tiers raise or remove these caps. Record counts are governed by the overall tenant storage tier, not by a per-object meter. Formula fields and validation rules are unmetered. If you anticipate running well past these numbers (hundreds of objects, hundreds of fields per object), the Scale and Enterprise tiers are the right conversation.
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.
We use cookies.
Essential cookies keep the site working. If you accept, we also enable Google Analytics
so we can see which pages help and which don't. Reject to opt out entirely. Details in our
Privacy Policy.
