I’m building a custom approval form with dynamic fields that should appear based on the request type selected. The conditional field logic works perfectly when I test as System Administrator, but when regular approvers (with the ‘Approver’ role) access the form, several dynamic fields remain hidden even when the conditions are met.
The fields are configured with visibility rules based on a lookup value, and I’ve verified the role-based permissions for the section allow read access to all fields. The form rendering seems inconsistent - sometimes the fields appear after a page refresh, other times they never show up. This is causing major delays in our approval process since approvers can’t see critical information needed for their decisions.
I checked the object permissions and found that the Approver role had read access to the section but not explicitly to the RequestType column. After adding column-level read permissions, the fields started appearing more consistently, but I’m still seeing intermittent issues where a page refresh is needed. Is there a caching mechanism that might be causing this delay?
I’ve dealt with this exact scenario multiple times. The issue stems from how Creatio 8.3 handles dynamic form rendering with role-based security. Here’s the comprehensive solution addressing all three key areas:
Conditional Field Logic:
Your business rules need to account for asynchronous permission loading. Instead of simple field visibility rules, implement a two-stage approach. First, ensure your business rule includes a permission check callback. In the Form Designer, modify your visibility rule to include an ‘on attribute load’ trigger that re-evaluates the condition after the lookup data and permissions are fully loaded. This prevents the race condition between form initialization and permission resolution.
Role-Based Permissions:
The core issue is granular column permissions. You’ve addressed the RequestType column, but you also need to verify permissions for the dependent fields (BudgetCode and CostCenter). Go to System Designer > Operation Permissions > Object Permissions, select your entity, and explicitly grant the Approver role READ access to:
- All columns used in business rule conditions
- All dynamically shown/hidden fields
- Any lookup reference columns these fields depend on
Additionally, check the ‘Can read’ operation at the section level isn’t overriding column permissions. Sometimes section-level restrictions cascade unexpectedly.
Form Rendering Checks:
The intermittent visibility and refresh requirement indicates a view model synchronization problem. Implement these fixes:
- Add an explicit dependencies declaration in your business rule to ensure proper load sequencing
- In the form schema, add a methods override that subscribes to the RequestType attribute change event and explicitly calls this.reloadEntity() for the dependent fields
- Clear the browser cache and metadata cache (System Designer > Clear Cache) after permission changes - stale metadata can cause rendering inconsistencies
For a more robust solution, consider using a custom detail with its own view model instead of dynamic fields on the main form. This gives you better control over the rendering lifecycle and permission evaluation. If you must use dynamic fields, add validation rules that make the fields required when they should be visible - this forces the form to ensure they’re loaded before allowing submission.
Finally, test with the browser’s network tab open to verify all permission and data requests complete successfully. Look for 403 errors that might be failing silently in the UI.
Yes, there’s client-side model caching that can cause this. The form’s view model might be initialized before all permission checks complete, especially for lookup-dependent fields. Try adding an explicit model refresh in your business rule or use the reloadEntity method to force a clean state when the controlling field changes. This ensures the visibility conditions are re-evaluated with fresh permission context.
This sounds like a client-side rendering issue combined with permissions. Have you checked the browser console for any JavaScript errors when the form loads? Also, are you using business rules or custom code for the conditional visibility?
Good point about the console - I see some warnings about attribute access being denied. I’m using business rules for the visibility logic, not custom code. The rules are straightforward: when RequestType equals ‘Capital Expense’, show BudgetCode and CostCenter fields. Could this be related to operation permissions on the lookup entity itself rather than the form fields?