Approval workflows
Approvals are how Rival Enterprise keeps a person in the loop on the decisions that change what your workspace can do: who may run a tool, what gets published, and which tools a whole team gets. Each of those is a request. It waits in one queue until an admin approves or rejects it, and the decision is recorded.
What raises a request
Section titled “What raises a request”There are three kinds of request, and all three land in the same queue.
| Request | Raised when | Approving it |
|---|---|---|
| Use a tool | A member opens a tool your policies mark request access, or one a global gate holds back (see below), and asks to run it | Grants that member access to that tool |
| Publish | A member publishes a function, agent or workflow to your organization or the public marketplace | Publishes it. Nothing is listed until the request is approved |
| Enable a tool for a team | A team lead asks for a tool to be switched on for their team | Enables the tool for everyone on that team |
A request carries what the admin needs to decide: who asked, the tool, the reason and expected volume they gave, urgency, and any risk flags Rival attached (for example, a tool that sends data outside your workspace, or one from an unverified builder).
How a request moves
Section titled “How a request moves”-
A member asks. The request is created with its details, and admins are notified.
-
An admin reviews it in Requests. For a publish request, the review shows exactly what would be published.
-
The admin approves or rejects, optionally with a note to the requester.
-
The requester is told, and on approval the access, listing or team setting takes effect straight away.
-
The decision is recorded — who decided, when, and the note — in the request’s history and the audit log.
If a policy change opens a tool while requests for it are still waiting, Rival approves those requests automatically and tells the requesters, so nobody waits on a question that has already been answered.
The gates that send a run to approval
Section titled “The gates that send a run to approval”Most requests come from tool policies: each tool is open, request access or blocked for your organization or a team. Three organization-wide gates, set in Guardrails & allowed models, can additionally hold back a tool that would otherwise be open:
- Unverified builder — a tool from a builder Rival has not verified needs approval before a member’s first run.
- Per-run cost cap — a tool whose price per run is above your cap (default $25) needs approval.
- Data residency — a tool that runs outside an approved region (US or EU) is blocked outright; this one cannot be approved past.
Who decides
Section titled “Who decides”Requests go to people with the governance capability in your workspace — Enterprise Admins by default. See the Capability matrix.
Keeping the queue useful
Section titled “Keeping the queue useful”- Open what is routine. A tool everyone should use belongs in open, not request access; approvals people have to click through for everyday work stop meaning anything.
- Use request access for real decisions — tools that reach external systems, cost significantly more, or come from builders you do not know.
- Leave a note on a rejection. It is what the requester sees, and it saves the same request coming back.