Access Control Errors

Use this guide when an application reports an Access Control error or shows runtime symptoms of missing or incomplete Access Control. These symptoms can affect data access, Entity operations, screen rendering, actions, and Process operations.

Lowgile may report the following runtime error when an operation is not permitted by the applicable Access Control configuration:

Access Denied based on Access control

The message identifies an Access Control denial, but it does not by itself identify which configuration must be changed.

Access Control failures are configuration-specific. Diagnose the denied object and operation before changing permissions; do not apply a Process permission to a data-access failure or broaden an unrelated rule.

For an explanation of what Access Control permits, see Access Control Fundamentals.

Recognize an Access Control error

Missing or incomplete Access Control can cause:

• A blank or incomplete screen.
• An included screen not to appear.
• A data binding not to resolve.
• An action to fail at runtime.
• A Process not to progress as expected.
• An explicit Access Denied based on Access control error.

These symptoms can also have causes unrelated to Access Control. Confirm the source of the failure before changing permissions.

Check the available diagnostic evidence

Reproduce the failing action once, then check both diagnostic locations:

1. Open the browser’s developer tools and review the Console for the runtime error and stack trace.
2. In Lowgile Studio, open Monitor → General Log and review the entries created when the action failed.
3. Open the detailed trace for the relevant General Log entry when one is available.
4. Record the application module, user action, named business object, and operation shown in the error.

For the complete Monitor procedure, see Debugging Your Lowgile App.

📝

Note

The browser and General Log may expose different parts of the failure. Use the object and operation identified by the evidence rather than assuming that every blank screen, failed action, or missing task is an Access Control problem.

If neither location identifies an Access Control denial, continue diagnosing the reported runtime error instead of changing Access Control.

Match the denied object or operation from the error to the corresponding tab in the Access Control editor:

Diagnostic evidence	Access Control area to review	What to identify
Loading, querying, creating, updating, or persisting data through a Server Data Store	ServerDataStore	The Server Data Store named by the error and the Entity involved in the data operation
An operation on a specific Entity	Entity	The named Entity and the exact denied operation
Starting or otherwise invoking a Process	Process	The named Process and the exact denied operation, such as start

Do not select an area from the visible symptom alone. For example, a screen can fail to render because its data request was denied; that does not make the screen itself the denied object.

Missing or incomplete Access Control coverage

If the application shows a blank or incomplete screen without an explicit error, confirm that the application has an Access Control component and that it covers the objects required by the affected screen or action.

For the verified procedure for creating an Access Control component and covering the Purchasing application’s Server Data Store, see Configure Access Control.

Do not add unrelated permissions while investigating an incomplete screen. Use the browser console and Monitor → General Log to identify the affected object whenever possible.

Server Data Store and data-access failures

When loading, querying, creating, updating, or persisting data fails:

1. Identify the Server Data Store and Entity named in the browser error or General Log entry.
2. Confirm that the application’s Access Control component covers that Server Data Store.
3. Confirm that the expected Entity is listed under the Server Data Store.
4. Compare the configuration with Configure Access Control.

The current documentation does not define a general rule-level fix for every Server Data Store operation. If the Server Data Store and Entity are covered but the operation is still denied, retain the diagnostic evidence and verify the intended permission with the application owner or Lowgile administrator rather than inserting unverified access logic.

Entity access failures

If the error identifies a specific Entity, record the Entity name and exact denied operation, then review the Entity area of the application’s Access Control component.

The current documentation confirms that Access Control can govern Entity and record operations, but it does not define a universal configuration for every Entity operation. Do not copy a Server Data Store or Process permission into an Entity rule. Retain the diagnostic evidence and verify the intended access requirements before changing the generated logic.

Operation denied by Access Control

An explicit Access Denied based on Access control message means that Access Control denied a runtime operation. The heading above describes this diagnostic scenario; it does not replace the exact platform error text.

Use the error and trace to identify:

• The affected Server Data Store, Entity, or Process.
• The exact operation that was denied.
• The caller that attempted the operation.
• The Access Control component that applies to the application.

Review only the restriction for the object and operation identified by that evidence.

Process start is denied

The current documentation supports one specific Process scenario: an authenticated client starting PurchaseRequestProcessing from the Purchasing application’s Submit Request action.

If the logs identify PurchaseRequestProcessing and its start operation:

1. Confirm that the Access Control component covers PurchaseRequestProcessing on the Process tab.
2. Confirm that you opened the generated start restriction rather than a different Process operation.
3. Confirm that a user is signed in and Sys.User.currentUser is available.
4. Keep the generated function signature unchanged. The application namespace and parameter names are generated for the current application and may differ from examples.
5. In the generated function, check for the current user and call allowClient() on the existing access-controller parameter:

if (Sys.User.currentUser) {
  accessController.allowClient()
}

Use the actual access-controller parameter name from the generated function. Do not copy accessController if the generated parameter has a different name. In this rule, Sys.User.currentUser limits the permission to a signed-in user, and allowClient() permits that authenticated client to invoke the start operation.

6. Save the Access Control component and wait for the application to rebuild.
7. Repeat Submit Request in the open application.

Do not generalize that configuration to other Process operations, Entities, or Server Data Stores. Their callers and permission requirements may differ.

💡

Insight

Process access controls whether the client can invoke a Process operation; it does not assign the resulting user tasks. If the Access Control error disappears but the expected task is not available, review the Process configuration, swimlane assignments, and the current user’s role. See Task Assignment & Process Responsibility for the distinction.

Verify the correction

After making a verified configuration correction:

1. Save the Access Control component.
2. Wait for the application to complete a successful rebuild.
3. Repeat the same action that produced the denial.
4. Check the browser console and Monitor → General Log again.

The Access Control denial should no longer appear for that operation. If a different error remains, diagnose it separately. Removing the Access Control denial confirms permission to attempt the operation; it does not confirm that every later application or Process step is configured correctly.

If the error continues

Collect the following information before escalating the issue:

• The complete browser-console error and stack trace.
• The relevant Monitor → General Log entry and detailed trace.
• The Access Control component name and selected tab.
• The Server Data Store, Entity, or Process name and exact operation.
• The application build result and the time of the failed test.
• The signed-in user and the action performed.

Provide this evidence to the application owner or Lowgile administrator. Do not weaken other access rules while testing an unresolved denial.

Related documentation

• Access Control Fundamentals
• Configure Access Control
• Build the Purchase Request Process Flow
• Debugging Your Lowgile App