Sales Operations System
Entirely new record types can be defined, not just new fields on the existing ones.
This is the ceiling on how far a CRM can stretch. If you need to track assets, sites, subscriptions or certifications as first-class records, a platform limited to custom fields will force you to distort an existing object or keep that data somewhere else.
Yes where an administrator can define an entirely new record type with its own fields, and relate it to the standard records.
Partial where a new type can be modelled only by repurposing an existing construct - another pipeline, another list - rather than by defining a genuinely new object.
No where the object set is fixed and extension is limited to adding fields.
Adding fields to an existing record is not a custom object, however many fields are permitted.
Custom Tables let an organisation create and customise new tables of its own without development work, and individual table entries are associated to Act! entities including contacts, companies, groups and opportunities, with activities and follow-up actions available against that data.
A custom object is a schema of related fields that can be attached to contacts, deals or accounts and appears as its own tab on those records. Objects can be defined in the interface through the data management page or through the Custom Objects API, and some third-party integrations create them directly. Availability of each of these routes varies by subscription.
No vendor document read describes creating a new object type. The documented model is a catalogue of supplied apps added and removed from an app store, extended by custom attributes within each app, with a reference app attribute used to point one app's record at another. Whether the suite offers a buyer-built app is not stated in the material available.
Workspace administrators can define entirely new object types alongside the standard ones, each with its own attributes and records. The number of objects a workspace may hold is governed by account limits, and the Companies and People objects count against that allowance. Custom objects do not have full parity with standard objects - email sync attaches only to person and company records, and outbound mail can only be addressed to people records.
The module set is fixed. The vendor defines modules as Pipelines, Contacts, Companies, Products, Activities and Dashboards, and the customisation documentation covers adding and arranging fields within those modules rather than creating a module. No vendor article describes defining a new object type.
The vendor's feature listing states that tailored data structures can be created beyond the standard People and Company records, and shows a custom object with its own properties alongside People, Company and Deals. No help centre article, API endpoint or attributes guide describes creating, populating or reporting on such an object, so the capability rests on a single product page claim.
Customisation extends a fixed set of record types. The custom field API accepts only parties, opportunities and projects as targets, and the vendor's customisation material describes adding fields, tags, DataTags, milestones, pipelines, lost reasons, activity types and task categories. No vendor documentation describes defining a new object type.
New object types are created in settings, each with its own field set of up to fifty fields and with fields that can be marked required. Instances always hang off a Lead, up to a combined limit of one hundred per lead, and can be referenced from opportunities, custom activities and other custom objects. Creation can be restricted to the API, and editing can be restricted by role.
Copper's record types are a fixed set - leads, people, companies, opportunities, tasks and projects. The customisation route is to rename those types in the singular and plural and to add fields to them. No vendor documentation describes defining a new record type.
The documented data model has a fixed set of record types - people, companies and deals - organised into groups, and extension is by adding custom fields to a group. No help centre article or API endpoint describes defining a new object type, and the API's object reference field type is documented specifically as linking deals to contacts. The vendor's public feature comparison carries a line pairing custom objects with deals, which reads as a reference to the built-in deal object rather than a mechanism for creating a new one, so the point needs vendor confirmation before publication.
Custom modules are genuinely new object types beyond the four core modules of contacts, accounts, deals and products. Each custom module gets its own name, icon, field set and records, supports CSV import, and can be linked to the core modules using lookup fields. A maximum of ten custom modules is documented.
New object types can be defined in the data model builder and associated with standard objects such as contacts, companies, deals and tickets. Creating and managing them requires account access permissions and the capability is restricted to HubSpot's top subscription level.
Custom Objects let an organisation define new record types for data the standard objects do not cover, place them in the left navigation, link their records to contacts and other records, and control access to them.
No vendor documentation found describes creating a new record type. The documented record types are contacts, companies, deals, tasks, appointments, notes and the commerce records, and the extensibility described everywhere in vendor material is custom fields on those existing types.
Makers create entirely new Dataverse tables, choosing standard, activity, virtual or elastic type and user/team or organisation ownership. Table type and ownership are fixed once the table is saved.
New record types are created by creating a board or a Data Set and defining its own columns - monday's own documentation gives lead tracking, contact databases, ticket systems and resource directories as examples of separate record tables - and those tables are related to the CRM entity boards with Connect Boards and mirror columns. The CRM's own Leads, Contacts, Accounts, Deals and Activities boards are instances of the same mechanism, so a buyer-defined object is a first-class citizen rather than a workaround.
Customisation is limited to extending the records Nimble already provides. The custom fields documentation covers contact and company records and deals only, and the API's field management endpoints create custom fields for contacts and deals. No facility to define a new record type is documented.
Nutshell's documented customisation model extends a fixed set of record types - companies, people, leads, activities and products - with custom fields and custom activity types. No vendor documentation describes defining a new object type, and the custom field workflow requires choosing one of the existing record types.
Pipedrive's documented customisation model extends a fixed set of entities - lead and deal, person, organisation, product and project - with additional fields. No vendor documentation describes defining a new object type, and the custom field workflow requires choosing one of those existing entities.
The documented customisation model extends a fixed hierarchy of record types - Company Group, Company, Contact, Opportunity, Problem, Quote, Enquiry and their interactions - by adding custom fields and configuring drop-down dictionaries. No vendor article describes defining a new record type, and the custom field workflow requires choosing an existing hierarchy level.
Administrators create entirely new object types in Setup, each with its own tab, relationships to other objects, page layouts and reporting.
The object model is fixed - box, contact, organisation, task, call log and meeting note - and vendor documentation describes no way to define a new object type. What can be created is a new pipeline, which carries its own stage set and its own columns and can track any class of record, so a new record type is modelled as another pipeline of boxes rather than as a genuinely new object. Boxes in different pipelines can be linked to one another.
Module Builder creates entirely new modules. An administrator sets the module's properties, defines its blocks and fields, sets default filters and creates relationships to existing modules, so a new object type with its own schema and its own links into the standard modules is a supported operation rather than a developer workaround.
Users holding the module customisation permission can build entirely new modules through a drag-and-drop module editor, and those modules can be linked to standard module records to form relationships. The permitted number of modules per account varies by subscription.