# Permissions & Data Access ## How Avonni Components Handle Security Avonni components run within your Salesforce org and adhere to the same security model as any native Salesforce feature. When a component queries data, Salesforce enforces your org's field-level security (FLS), object permissions (CRUD), and sharing rules. This page covers how that works in practice, what the "Strip Inaccessible Fields" setting does, and how to troubleshoot common permission-related issues. *** ## Object and Field Permissions Before a component can display data, Salesforce checks whether the running user has access to the object and fields being queried. ### Object-level access If a user doesn't have Read permission on an object, any query that references that object will fail entirely. This includes relationship fields — if your Data Table queries Accounts and includes `Account.Owner.Manager.Name`, the user needs Read access to the User object for that relationship to resolve. When a query references a related object the user can't access, the query fails at parse time. Salesforce doesn't return partial results — the entire query throws an error. ### Field-level access If a user has access to the object but not to a specific field, the behavior depends on how the component is configured: * **Without "Strip Inaccessible Fields":** The query runs but Salesforce may throw a security exception if FLS isn't enforced in the Apex code. * **With "Strip Inaccessible Fields" enabled:** The query runs, and fields the user can't access are silently removed from the results. The component displays what the user is allowed to see. *** ## What "Strip Inaccessible Fields" Actually Does The "Strip Inaccessible Fields" toggle (available on components with data sources) runs `Security.stripInaccessible()` **after** the query returns results. It removes fields from the result set that the user doesn't have FLS access to. ### What it handles * Fields the user can't read are removed from query results * The component renders without those fields (columns appear empty or are hidden) * No error is thrown — the component works, just with fewer fields visible ### What it doesn't handle * **Object-level access failures.** If the user can't access the object at all, the query fails before `stripInaccessible` ever runs. The toggle has no effect. * **Relationship object access.** If a query includes a lookup to an object the user can't read (e.g., querying Contacts with `Account.ParentId` where the user can't read Accounts), the SOQL fails at parse time. Strip Inaccessible Fields only processes results — if there are no results, there's nothing to strip. * **Aggregate or formula fields** that reference inaccessible fields behind the scenes. In short: **Strip Inaccessible Fields is a post-query safety net, not a pre-query filter.** It can't fix a query that couldn't run in the first place. *** ## Visibility Rules and Custom Permissions Avonni components support visibility rules based on custom permissions. A component becomes visible or hidden based on whether the running user has a specific custom permission assigned. ### How it works 1. The component checks if the running user has the custom permission 2. Based on the result, the component is shown or hidden 3. This check runs every time the page or screen loads ### Common issue: visibility rules not evaluating correctly If a visibility rule based on a custom permission doesn't work as expected — for example, all users see the same result regardless of whether they have the permission — the root cause is usually how Salesforce handles the permission check. **Troubleshooting steps:** 1. **Confirm the custom permission exists** in Setup > Custom Permissions 2. **Confirm it's assigned** to the right permission set, and that permission set is assigned to the right users 3. **Test with a non-admin user.** System administrators bypass many permission checks. Always test visibility rules with a standard user profile. 4. **Check your Avonni package version.** Earlier versions had an issue where the underlying query used `USER_MODE` for Setup entities, which prevented standard users from reading custom permission metadata. This was fixed — make sure you're on the latest version. *** ## Troubleshooting ### "My Component Shows No Data" When a component appears but shows no records, work through these checks in order: #### 1. Is it a permission issue? Open the browser console (F12) and look for error messages. Common ones: * `Insufficient privileges` or `No access to entity` — The user can't read the object being queried * `Field is not accessible` — FLS is blocking a specific field * No error at all, just empty results — Could be sharing rules limiting the record set #### 2. Does it work for an admin? Log in as an admin and load the same page/screen. If the admin sees data but the user doesn't, it's almost certainly a permission or sharing issue. #### 3. Check sharing rules Even if a user has object and field access, sharing rules control *which records* they can see. If the user's role doesn't grant access to the records in the query, results will be empty. #### 4. Check the "Strip Inaccessible Fields" toggle If this toggle is off and the user lacks FLS on a queried field, the component may throw an error instead of showing partial data. Try enabling it to see if the component loads with reduced fields. #### 5. Check relationship fields If your query includes lookup fields to other objects (e.g., `Contact.Account.Name`), verify the user has Read access to each object in the chain. A single broken link in the relationship chain will cause the entire query to fail. ### Custom Permission Visibility Not Working | Symptom | Likely cause | Fix | | --------------------------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------- | | All users see the component (even without the permission) | Permission check returning `undefined` instead of `false` | Update to latest package version | | No users see the component (even with the permission) | Custom permission not assigned via permission set | Assign the permission set to the users | | Works for admins, not for standard users | Admin profile bypasses permission checks | Test with standard user; assign permission set explicitly | | Intermittent — sometimes works, sometimes doesn't | Browser caching or session issues | Test in incognito; clear cache | ### Deployment & Permission Sets When deploying Avonni components between environments (sandbox to production), remember: * **Avonni permission sets** must be assigned separately in each environment. Deploying a page layout doesn't carry over permission set assignments. * **Custom permissions** used in visibility rules must exist in the target environment. If they don't, the visibility rule will silently fail (the component may always hide or always show). * **Package licenses** must be assigned to users in each environment. A deployed component won't render if the user doesn't have the Avonni package license in that org. See also: [Installation & Licenses Management](/flow/getting-started/installation-and-licenses-management.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.avonnicomponents.com/flow/help/permissions-and-data-access.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.