Structured records
Each record has defined fields, defined relationships, and a defined role in the operation — modelled around the business process.
Operational data and access are configured together in L3RA. The records the business actually works on, the operational views different roles need, and the users, roles, and groups that govern access are part of the same layer.
Records, operational views, and files connected to records are configured inside the operational layer. Together they describe the work as an object the system knows how to handle — not a pile of disconnected rows.
Each record has defined fields, defined relationships, and a defined role in the operation — modelled around the business process.
Records are surfaced for different roles and working contexts. The same operation can be read through several role-shaped views.
Supporting files stay with the record they belong to — not in a parallel folder structure on the side.
Users, roles, and groups are part of the operational layer — not a separate identity product layered on top. The same role definitions that govern workflow steps also define who sees which records and which operational views.
People allowed into the operational layer. Each user belongs to the operation through their role — not through a global account.
Roles describe what a person does in the operation. Workflow steps, operational views, and actions are configured around roles — not around individuals.
Groups collect users that share an operational context: a team, a partner, a function. Access can be reasoned about at the group level.
Configured to match existing policies where applicable. The company keeps its own identity practices intact.
Activity visibility is designed for organizations that need activity context over time. Records carry the steps taken, the roles that took them, and the context they happened in — without separate tooling on the side.
Each activity event names the operational step it belongs to.
Activity context is attached to the role responsible at the moment of action.
Activity stays with the record, so the operation has its own activity context.
Five mechanisms describe how the data and access layers actually work together. They are the same five pieces, applied to every operation L3RA carries.
Operational data is organized around the business process. Each record has defined fields, defined relationships, and a defined role in the operation. Records are not raw rows; they are objects the workflow knows how to handle.
Records are surfaced for different roles and working contexts. The operations team, a manager, a partner, and a requester see the same operation through different operational views.
Files are connected to the record they belong to. Supporting documents stay with the operation that produced them — not in a parallel folder structure.
Access is organized to match organizational responsibility. The same role definitions that govern workflow steps also govern who sees which records and which operational views.
Configured to match existing policies. Authentication is one of the surrounding systems L3RA cooperates with — it does not replace the company’s identity practice.
A record is the operational object the workflow moves through. It carries the fields the operation needs, the relationships it depends on, and the access context that decides who can act on it.