Hook
If you've ever assumed Domo's "All Rows" PDP entry was just a UI label — not a real policy object — you'd be wrong, and that misunderstanding can silently break how you manage row-level permissions programmatically.
Why It Matters
Row-level security in Domo is enforced through PDP (Personalized Data Permissions), but the API surface behind it is underexplored. Without understanding how policies map to API objects, you can't reliably automate permission management, audit who has access to what, or build tooling that interacts with the Data Control endpoints. Knowing that "All Rows" is a concrete policy object — with its own ID — changes how you write PUT requests to manage group and user access.
What You'll Learn
- Confirm PDP is enabled on a dataset using the
v1/datacollection/{datasetId}endpoint - Query filter groups via the
datacontrol/{datasetId}/filtergroupsendpoint to enumerate all active policies - Understand why the All Rows policy has a real policy ID and must be treated as a first-class object in API calls
- Assign specific groups and users to a policy by constructing the correct PUT request body with
groupIdanduserIdfields - Get a first look at Columnar PDP beta — field-level security coming to Domo
PDP from the Network Tab: What the API Actually Shows You
The most useful habit when working with Domo's UI is watching the browser's network panel in parallel. Every UI action maps to a real API call, and that's where the implementation details live.
Starting with PUT /v1/datacontrol/{datasetId} — this endpoint tells you whether PDP is enabled on a dataset. It's a status check, not a policy list. To get the actual policies, you need GET /datacontrol/{datasetId}/filtergroups, which returns an array of policy objects. In the demo, this response surfaces two objects: the All Rows policy (ID 2242) and a named filter group (ID 2289).
The critical insight: the All Rows policy is not a UI abstraction. It is a real policy object with a stable ID that you can target directly in a PUT request. To modify who gets all-rows access, you send a PUT to /datacontrol/{policyId} with a body that includes groupId and userId arrays — the same structure used for any other PDP policy.
For the Columnar PDP beta, the concept extends this model from row filtering to column filtering, letting you restrict which fields a group or user can see. The API shape follows the same pattern, making it a natural extension if you're already scripting row-level policy management.
If you're building automation around Domo's permission layer — onboarding workflows, audit scripts, or multi-tenant data access tooling — treating PDP policies as first-class API objects (with stable IDs you can enumerate and target) is the right mental model.
