Decide what not to govern
Building a connector, step 5 of 10. Previous: Model Grant kinds.
An API exposing a relationship does not make it access worth governing. Put every row of your design table through the questions below. Each row ends in one of five outcomes, and rejected rows stay in the table with their reason, so the next person knows it was a decision. Leave something out because it is not access, does not scale or cannot be written safely, not merely because it is hard.
The outcomes
| Outcome | Use it when | In the connector |
|---|---|---|
| Writable Grant kind | It is access, Sync can list it, and it has an exact add and remove with readable answers | writable: true and both write operations |
| Read-only Grant kind | It is access worth reviewing, but Owlie cannot write it safely or at all | A Grant kind without writable |
| Read-only account attribute | It is a property of the account, such as an admin flag or account type | A readOnly property on the account |
| Custom operation | It is a useful action, but not an assignment Owlie can list, add and remove | A custom operation |
| Not modeled | It is not access, does not scale, or does not fit the access model | A row in your table with the reason |
The questions
Ask them in order. The first "no" usually decides.
Does holding it let the person do something in the system?
Billing, marketing audiences, HR placement, catalog structure and reporting lines look like relationships but are not access to the system. Leave them out of a new connector:
- A Stripe subscription to a price is billing. It grants no Stripe permission, and cancelling a subscription to remove one price could stop billing for its other items.
- Klaviyo list and segment membership is audience classification, not Klaviyo access.
- A QuickBooks employee record is a worker, not a login. NetSuite department and location, and Workday organization assignments, describe where someone sits, not what they can do.
- An HR system of record such as BambooHR is an identity source: sync its people and write nothing.
Some of Owlie's catalog connectors still show relationships like these as read-only Grant kinds, kept for compatibility with their earlier versions. That is not a precedent for a new connector.
Does it grow with people, or with content?
Access that grows with the number of files, pages, channels or repositories (permissions on individual content) is not modeled without a deliberate product decision. Owlie's connectors do not model Google Drive file permissions, Slack channel membership or GitHub repository permissions. Confluence space permissions are shown read-only, and Box file collaborations are offered as custom operations instead.
Can Sync read it completely?
Access with no list call cannot be a Grant kind. A listing that mixes direct and inherited access without saying which, or that includes holders Owlie cannot identify, cannot prove what to remove. SharePoint and OneDrive item permissions are read-only for that reason, and anonymous sharing links, which have no single holder, are not modeled.
Can Owlie add it and remove it exactly?
- No write API. Xero's API reads user roles but has no call to assign them.
- One required slot with no safe way to clear it. Zoho CRM role and profile, Zoom account roles and HubSpot roles: a "remove" would have to choose a replacement, which is a policy decision.
- Side effects. Resetting a Lever access role also removes followed profiles.
- Moves, not assignments. Placing a user in a Google organizational unit moves them; there is no matching remove.
- Writes that cannot be confirmed. An invitation proves nothing until it is accepted, and an asynchronous bulk job cannot confirm one change. Calendly's invite and remove are custom operations.
- Inherited rows. ServiceNow writes direct role assignments only; inherited rows are shown but never removed as if they were direct.
Does it fit the access model without bending it?
If a kind of access needs a holder or scope the model does not have, leave it out and note why. Application permissions on SharePoint sites would need an application principal; Google licence assignment would need a separate licence catalog. Do not invent structure to make it fit.
Is it a persistent assignment, or a runtime decision?
Conditional access policies and just-in-time elevation are decisions the system makes at sign-in. Observe the persistent object behind them if it is worth reviewing, and never claim the runtime answer. Microsoft Entra ID's connector reads role eligibility read-only and never treats it as a held role.
Is it already modeled another way?
Slack user groups can be reached through two APIs. One Grant kind covers them, not two.
Do not leave out what is merely hard
These were difficult and were modeled anyway:
- Roles scoped to a container. A role held inside one organization, and Entra ID directory roles scoped to an administrative unit, carry the scope as a qualifier, instead of being dropped or flattened.
- Awkward write answers. Slack Enterprise Grid reports partial failures inside a successful response; its connector reads them and writes the Grants anyway.
- Accounts owned elsewhere. Confluence, Jira, Marketo and monday.com create accounts outside Owlie. Their connectors are Grants-only: they govern access and leave the account's lifecycle to the other system.
Record the decision
Give every rejected row its status (read-only, custom operation or not modeled), the reason in one line, and a link to the vendor documentation behind it. Put anything a customer of that system might expect to see governed in your README's limits too.
Next: Choose a kind