This content originally appeared on DEV Community and was authored by Nikhil Sarpatwari
We recently needed to expose a small subset of fields from the Contact and Account tables to an external API, such as firstname, lastname, and emailaddress1. At the same time, we had to ensure sensitive fields like ssn, birthdate, and internal notes remained inaccessible.
After evaluating different approaches, here are the two most practical and secure methods to achieve this in Dataverse: using Column-Level Security (CLS) or creating a dedicated minimal table for API exposure.
What Are We Trying to Solve?
We aim to:
- Allow the API user to retrieve only specific columns.
- Prevent access to sensitive columns in the Contact and Account tables.
- Ensure internal users remain unaffected and retain full access.
Option 1 - Using Column-Level Security (CLS)
This approach is suitable when the number of columns to restrict is manageable.
Step 1 - Set Up a Dedicated API Security Role
Create a new security role that grants the API user read access to the Contact and Account tables. Field-level control will be managed through CLS.
Step 2 - Enable CLS on All Sensitive Fields
In both tables, enable column-level security for every field that should not be accessible to the API, such as ssn, birthdate, creditlimit, and internal notes.
Important: Columns not enabled for CLS are fully accessible to any user with read access to the table.
Step 3 - Create a CLS Profile for the API User
Create a new CLS profile (e.g., API_ReadOnly_LimitedFields) and include only the fields you want the API to access.
Set permissions for these fields as follows:
- Read: Yes
- Update: No
- Create: No
Assign this profile to the API user (e.g., App User or Azure AD Registered App).
Step 4 - Create a CLS Profile for Internal Users
To ensure internal users are not restricted by CLS, create another profile (e.g., Internal_FullAccess) and include all CLS-enabled columns with full read, update, and create permissions.
Assign this profile to the security roles used by internal users.
Step 5 - Test API Access
When the API queries the table, for example:
GET /contacts?$select=firstname,lastname,emailaddress1,ssn
It will only receive values for firstname, lastname, and emailaddress1. Restricted fields like ssn will either return blank or throw a 403 error, depending on the platform and configuration.
Option 2 - Create a Dedicated Table for API Use
If the API only needs a subset of fields and does not require the full schema of the Contact or Account tables, this approach is cleaner and often easier to maintain.
Why This Works Well
Create a new table, e.g., PublicContactSummary, with only the fields safe to expose.
Populate this table using a plugin, Power Automate flow, or Azure Function.
Expose only this new table to the API user.
This approach avoids:
- Enabling CLS for every sensitive column.
- The risk of accidentally exposing fields if CLS is misconfigured.
- Extensive testing cycles and managing multiple CLS profiles.
- Additional Benefits
- Reduced testing and development overhead.
- Complete separation of internal and API logic.
- Easier versioning and evolution of API-facing models without impacting internal systems.
Summary
To expose only a handful of fields to an external API, consider these two options:
Use CLS If:
- You prefer to use the existing Contact or Account tables.
- You are comfortable managing CLS on sensitive fields.
- You have tight control over field-level access.
Create a Dedicated Table If:
- You want a low-risk, low-effort solution.
- The API requires only a few fields.
- You want to avoid modifying existing internal logic or security profiles.
In our case, we opted for CLS because the number of restricted fields was small and manageable. However, for future API requirements, we will likely choose the dedicated table approach - it is cleaner, easier to test, and offers greater flexibility with lower risk.
This content originally appeared on DEV Community and was authored by Nikhil Sarpatwari
Nikhil Sarpatwari | Sciencx (2025-07-28T01:41:39+00:00) Controlling API Access to Specific Fields in Dataverse. Retrieved from https://www.scien.cx/2025/07/28/controlling-api-access-to-specific-fields-in-dataverse/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.