Access Control Fundamentals

Access control defines the permissions that exist within a Lowgile application.

It determines what the system is allowed to do:

• What data can be accessed,
• Which operations are permitted, and
• Which screens and actions can execute.

These permissions form the foundation for user roles and screen behaviour, and influence how data is accessed within workflows.

When access control is correctly configured, it is largely invisible. When it is missing or incomplete, screens may appear blank, actions may fail to execute, and workflows may not progress as expected.

What access control is

Access control defines permissions at a granular level. It specifies exactly which operations are permitted on entities, records, screens, and actions.

For example:

• Which entities can be accessed,
• Which records can be created or modified,
• Which screens can be rendered, and
• Which actions can be executed.

Access control operates at the capability level. It defines what the system permits, without reference to individual users.

What access control is not

Access control does not:

• Assign permissions directly to users,
• Define approval workflows, nor
• Determine who approves or rejects requests.

These responsibilities are handled by user roles and workflow processing, which build on top of access control.

Process access control

Process Access Control governs whether a caller can invoke an operation on a Process. When a Process is covered on an Access Control component’s Process tab, Lowgile provides restrictions for operations that can be controlled, such as start.

Each restriction has a generated function signature. Its application namespace and parameter names reflect the current application, so keep that signature unchanged. Within the restriction, allowClient() permits the client to invoke the operation when the rule’s conditions are met. Call it on the access-controller parameter generated for that function rather than copying a parameter name from another application.

For example, a rule can check Sys.User.currentUser before calling allowClient() to restrict client access to a signed-in user. This permission only allows the client to invoke the selected Process operation. It does not assign the tasks created after the Process starts; task responsibility remains controlled by the Process’s swimlane and role assignments. See Task Assignment & Process Responsibility.

Screen visibility and runtime behavior

Access control is required at runtime. If a screen references an entity, field, or action that is not permitted by the relevant permissions, it may fail to render correctly.

This may result in:

• Screens not rendering,
• Included screens not appearing, or
• Data bindings failing to resolve.

🛠️

Troubleshooting Tip

In these cases, the application may start successfully but display a blank screen or incomplete UI without an explicit error. This is a common indicator of missing or incomplete access control.

Access control does not restrict what you can design in the builder. You can create screens, bind entity data, embed screens within each other, and configure layouts and actions without access control being configured.

For this reason, configure access control before running or testing an application.