Objects, records, and relationships

Every business has important “things” it keeps track of: customers, projects, orders, cases, documents, assets, or applications.

Paraline calls each type of thing an object. One individual customer, project, or case is a record. A relationship explains how records are connected.

For example:

• Customer and Service case are objects.
• Acme Industries and case SC-1048 are records.
• “Case SC-1048 was opened by Acme Industries” is a relationship.

These ideas give people, workflows, integrations, and AI a shared understanding of the business.

Why structure matters

A spreadsheet can store a customer name beside a case description, but copied text does not reliably establish identity. If the customer changes its name, or several cases belong to the same customer, the connection becomes harder to maintain.

Structured records solve that problem. The customer has one stable identity. Each case has its own state. Relationships connect them without copying the entire customer into every row.

This structure lets the operation answer useful questions:

• Which open cases belong to this customer?
• Which asset is affected?
• Which documents support the case?
• Which tasks must finish before it can close?
• Who is allowed to see or change each record?

An object is more than a list of fields

An object defines the business meaning around a type of record. It can include:

• a stable identity;
• required and optional information;
• valid states;
• relationships to other records;
• actions the business recognizes;
• and permissions that apply.

A Service case, for example, might contain a subject, priority, owner, status, opening date, and relationship to a customer. The business may allow the actions assign, request information, escalate, and resolve.

The object should be designed around the decisions and responsibilities the operation needs—not simply around the columns that happen to exist in a source file.

Records keep stable identity

A record should remain the same record when its name, owner, or status changes. Stable identity allows history, relationships, permissions, and external references to continue pointing to it.

External systems may use different identifiers. A customer can have one ID in a CRM and another in an accounting platform. Paraline can preserve those references without confusing either one with the workspace record’s identity.

This becomes important during imports. A source row may appear similar to an existing customer, but similarity is not the same as identity. Strong external IDs or approved matching rules may support an automatic update. Ambiguous matches should be reviewed rather than silently merged.

Relationships preserve context

Different relationship shapes support different business situations.

One to one

One service case may have one final resolution summary.

One to many

One customer may have many service cases, each with its own owner and state.

Many to many

Several people may work on several projects. The relationship can also record each person’s role or dates.

Hierarchy

An organization may contain departments, or a project may contain tasks and subtasks.

Keeping these connections explicit gives AI better context and gives people a more understandable view of the operation.

Not every field plays the same role

Treating every value as editable text creates problems. A calculated “days open” value can disagree with the opening date. A free-text status makes it difficult to enforce a workflow. A copied customer name can break a relationship.

Important state changes belong to actions

Changing a case from waiting to resolved may require a resolution note, completed tasks, an approval, and a customer notification.

Instead of allowing every interface to edit the status field directly, a defined resolve_case action can check those conditions and record the result.

The same action can serve a person clicking a button, an AI agent requesting a tool, or a workflow reaching the final step. The rule remains consistent.

Specialized businesses can use specialized objects

A medical-form operation might use Patient record, Form request, and Clinical review. A repair company might use Asset, Repair order, and Estimate. An agency might use Client, Engagement, and Deliverable.

Custom objects let the software match the business. They should still benefit from the same identity, permission, action, workflow, and history principles.

Changing the model affects live work

Adding a field is often simple. Renaming a field, changing a relationship, or removing a status can affect existing records, views, workflows, and integrations.

For that reason, a proposed change should show what will be affected and whether data needs to be migrated. Consequential or destructive changes need review and a recovery plan.

Continue to Views, actions, and events to see how connected data becomes usable business software.