Configurable Business Software: Objects, Fields, and Permissions
July 13, 2026 · AmplySales Team
What is configurable business software?
Configurable business software lets a company describe data and workflows as configuration: which records exist, which fields they contain, how records relate, who can see them, and what should happen after an event.
It sits between two extremes:
- rigid packaged software, where the business must fit a fixed set of screens;
- software built from scratch, where every new object, field, or action becomes a development and maintenance task.
A configurable platform provides the records, permissions, interface, and automation engine, while allowing the company model to be built on top.
Objects are the nouns of the business
An object describes one type of business record. Standard CRM objects include accounts, contacts, and deals. Another process might need:
- equipment;
- agreements;
- service cases;
- inspections;
- sites or locations;
- partner submissions;
- projects or work stages.
Creating an object means more than adding a database table. The system must define how users read, create, edit, search, relate, and archive those records.
Fields give objects meaning
A field can be text, number, date, option, checkbox, user, file, or a reference to another object. A sound model uses the appropriate type rather than storing everything as free text.
For example, a service-case status can be a controlled option, the owner a user reference, and the equipment a lookup to an equipment record. This allows the system to validate input, filter reliably, and run deterministic rules.
Relationships turn lists into a system
Business software becomes valuable when objects are not isolated lists. A contact may relate to several companies, a deal to products and contact roles, and a service case to specific equipment and an agreement.
When modeling a relationship, ask:
- can one record connect to one or many records;
- does the relationship itself need data, such as role or validity dates;
- where will users see and edit the relationship;
- what should deletion or archiving do to the other side.
Without those decisions, the same information spreads across free-text fields and automation cannot know which value is authoritative.
Permissions must reflect real responsibility
A flexible data model needs an equally deliberate access model. NIST's least-privilege principle says a user, or process acting on their behalf, should receive only the minimum access needed for the task.
In practice, separate:
- object permission – can the user read, create, edit, or delete this kind of record;
- record permission – can they see their own, their team's, or the organization's records;
- field permission – can they view or edit a sensitive field;
- action permission – may the user or agent send email, import data, or update related records.
Automation is the verb
If objects are nouns and fields are attributes, actions are verbs:
- create a record;
- update a field;
- notify an owner;
- send an email;
- create a task;
- update a related record;
- send data to another system;
- run a permission-bounded AI agent.
Good automation is generic to the data model. The same “record created” trigger and “create related record” action should be usable for a deal, service case, or an organization's custom object.
When does configuration become dangerous?
Flexibility creates a different kind of disorder without governance.
One concept gets several fields
“Customer type,” “account category,” and “client class” may begin describing the same thing. Existing definitions should be checked before adding another field.
A change breaks reports or automation
Renaming a field, removing an option, or changing a relationship can affect filters, imports, and rules. Configuration needs change history and testing.
Access remains too broad
A new object may work technically while being exposed to the wrong role. Default visibility must be deliberate, especially for portals and AI use.
The platform becomes custom code by another name
If every customer exception becomes a code branch, the configurable-platform advantage disappears. Stable capabilities should be reusable primitives, while customer process remains data-driven configuration.
The AmplySales model
AmplySales uses one records engine for standard CRM records and organization-defined custom objects. Administrators can configure fields, options, layouts, related lists, profiles, object permissions, and field access. Automations and Managed Agents work inside the same organization and user boundaries.
This lets a team begin with sales and CRM, then add its own work objects without commissioning a separate application. It does not mean the platform is a complete prebuilt solution for every industry. The data model, workflow, and permissions still require deliberate design.
For category boundaries, read CRM, business platform, or ERP. For workflow boundaries, continue with sales automation.