docs(api): add common multi-step API tasks page

[mindymo]

Summary

• Adds conductorone-api/common-tasks.mdx, a cookbook page covering API tasks that require chaining 2+ calls (e.g. adding an entitlement to an access profile, checking provisioning status, extending/removing a grant's expiration, executing an automation and checking its result).
• Wires the new page into the API tab nav in docs.json, after pagination.
• Motivated by analysis of the docs assistant's chat logs: many customer questions asked for exactly these call chains, which aren't covered by the auto-generated per-endpoint reference (which documents one endpoint at a time, not workflows).

Review notes

Several steps are marked with <Warning> callouts as Needs verification — these are our best reconstruction from the API reference, not confirmed against a live tenant:

• Whether an entitlement's risk level attribute value can actually be attached to a specific entitlement, and via which endpoint/field (couldn't find this in the reference at all).
• The exact taskTypes/taskStates semantics for counting access profile provisioning completion.
• The full set of automation execution state values.
• Whether a service principal can be set as an app owner via the API (the reference doesn't say either way).

Requesting review from someone on the sales engineering team to confirm/correct these before this goes out more broadly.

Test plan

• Verify the flagged endpoints/behaviors against a live tenant
• Preview the page renders correctly in Mintlify

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
conductorone	🟢 Ready	View Preview	Sep 23, 2026, 5:49 PM

[mindymo]

Re-reviewed this against the live OpenAPI spec and pushed fixes in 5096640 — flagging here since this has been open a while without review.

Fixed (would have failed for anyone following the doc):

• "Check how many users have completed provisioning" — the task search used "taskTypes": ["TASK_TYPE_GRANT"], but taskTypes is an array of TaskType objects, not strings. Fixed to { "grant": {} }. Also added grantOutcomes: ["GRANT_OUTCOME_GRANTED"] filtering, since a closed task can be denied/errored/cancelled, not just successfully granted.
• "Extend or remove a grant's expiration date" — step 1 called POST .../entitlements/{id}/search-grants, which isn't a real endpoint. Replaced with POST /api/v1/search/app_users to look up the app_user_id — update-grant-duration never actually needed a grant ID.

Resolved directly from the spec (no longer needs verification):

• Risk level is set via riskLevelValueId on the standard entitlement update call.
• Automation execution state has a full enum: DONE = success, ERROR/TERMINATE = failure, PENDING/CREATING/GET_STEP/PROCESS_STEP/COMPLETE_STEP = in progress, WAITING/PAUSED_BY_CIRCUIT_BREAKER = stalled, needs resolve_paused/clear.

Still open: whether a service principal can be set as an app owner via POST /api/v1/apps/{app_id}/owners/{user_id} — the spec doesn't state it either way. Still needs someone from sales engineering (or eng) to confirm against a live tenant before this ships.

Everything else in the page checked out against the spec as originally drafted.