Views, actions, and events

Records describe what exists. A business also needs to see the work, change it safely, and understand what happened.

Paraline uses three ideas for that:

• a view presents information for a purpose;
• an action defines a valid business operation;
• an event records that something meaningful occurred.

Together, they connect the interfaces people use with the tools, workflows, and history behind the operation.

Views help people do a job

A view is not a copy of the data. It is a useful way of presenting the same records for a particular responsibility.

The same service cases might appear in:

• an intake table for new requests;
• a work queue for one team;
• a customer timeline;
• an overdue dashboard;
• or an approval inbox.

Each view answers a different question while referring to the same underlying cases.

Table

Helps a user scan, filter, sort, compare, and perform high-volume work.

Detail page

Brings one record together with related information, evidence, history, and available actions.

Queue

Surfaces work that needs attention, assignment, correction, or review.

Form

Collects validated information for a known action rather than editing arbitrary data.

Dashboard

Summarizes trends and outcomes while linking back to the records behind the numbers.

A view should respect the actor’s permission. Hiding a field on one screen is not a security boundary if the same user or agent can retrieve it elsewhere.

Actions express business meaning

An action is more specific than “change this field.” It represents something the business recognizes, such as:

• assign a case;
• approve a refund;
• request missing information;
• send an approved response;
• close an opportunity.

The action can define what information is required, who may request it, which state must already be true, whether approval is needed, what changes, and what happens if execution fails.

Consider send_customer_resolution. It may require a resolved case, approved content, a valid customer contact, and authority to communicate externally. It can record the outgoing message, call the delivery provider, and preserve the provider’s result.

That one contract is more dependable than rebuilding the rules in every screen, workflow, and AI prompt.

Read actions matter too

An action does not have to change data. Searching permitted records, calculating a quote, or previewing a proposed change can still benefit from clear input, permission, and a structured result.

Read actions are especially useful for agents. A purpose-built tool can return the exact context needed for one responsibility without exposing unrestricted database access.

Events are facts

An action asks for something to happen. An event records what actually happened.

message.send_requested and message.delivered are not the same fact. The provider might accept the request and later report a delivery failure.

send requested
      ↓
permission and approval checked
      ↓
provider accepts request
      ↓
send recorded
      ↓
provider reports delivery result
      ↓
delivery or failure recorded

Separating request from result prevents the workflow from reporting success too early. It also gives operators a useful timeline when something goes wrong.

The same action can serve several actors

A person may click “Assign.” An AI agent may request an assign_case tool. A workflow may assign the case after a rule matches. An API client may make the same request from another application.

The presentation differs, but the operating layer can apply the same checks:

• Which workspace and record are involved?
• Who or what is acting?
• Is the current state compatible with the request?
• Are the inputs valid?
• Does the actor have permission?
• Is approval required?
• What result or error should be recorded?

This is how Paraline avoids having one set of rules for people and another for agents.

High-impact actions should be previewable

For consequential work, proposal and execution can be separate.

An AI or employee first prepares a structured change. The application shows the target, source evidence, expected effect, and any uncertainty. An authorized reviewer approves or corrects it. The runtime then executes the approved parameters.

The review should focus on the decision, not force the user to read an entire AI transcript.

Events make workflows measurable

Events can start a workflow, advance a waiting process, notify another system, or contribute to performance measures.

They also help define completion. If a workflow’s goal is to deliver an approved customer response, completing the draft is not enough. The relevant event may be successful delivery—or an explicit failure that creates an operator task.

The history can then answer:

• what was requested;
• which rule and approval applied;
• which action ran;
• what changed internally;
• what the external system reported;
• and what work remains.

Continue to Versioning and publishing to learn how changes to these definitions can be reviewed before they affect live work.