Section 1 - Overview
Now Assist reporting (Now Assist Analytics and Subscription Management) shows how many assists an organization consumes, but nothing in the platform acts when one team or one power user consumes too many. This post describes a governance loop built entirely from out of box capabilities. It detects over-consumption with a report, warns users before the budget runs out, pauses the affected skill for whoever exceeded it, and restores access automatically when the period resets. A manager can lift the pause early through a normal approval. No custom tables, no scoped app.
Figure 1. The governance loop of threshold alerts, skill removal, and restore
Section 2 - What the solution builds on
Two platform properties make governance possible without any custom development:
- OOTB AI Usage table - Every metered execution writes a row to sys_gen_ai_usage_log carrying the user, the skill, and the assist count.
- OOTB user field is a true reference - consumption rolls up from user to department, group, or manager.
Figure 2. The usage ledger - Every metered execution is one row carrying the user, the skill, and the assist count.
Skill access is gated by a role and a group the administrator controls. A Now Assist skill is available to users who hold the skill's configured role along with the panel role. Access is a grant the platform already audits. Grant the role broadly, withdraw it from exactly the team or person who exceeds budget, and mark the suspension with membership in a dedicated group.
Section 3 - How to set it up
Step 1. Gate the skill with a role and a group you own
Identify the role the skill checks in its configuration and grant it to the people who should have the skill. Grant it directly to each user when you want the option to pause one person, or to a group when pausing a whole team is enough.
Figure 3. The governed skill configuration, with the role attribution and applicability that gate access to it.
Figure 4. The skill role granted directly to a governed user, alongside the panel role that arrives through group membership.
Then create a group named for the suspension, for example "Now Assist Suspended - Resolution Notes." The group does no enforcement by itself. It exists as a clean, platform-audited record of who is paused and why.
Step 2. Set the budgets
Decide a monthly assist budget per team and per person for each governed skill, and store the numbers as system properties so the automation can read them. Treat these as policy figures owned by the platform team, not license figures. In the verified build they were 3,000 per team and 400 per person.
Step 3. Build the detection report
Create a bar report on sys_gen_ai_usage_log that groups by user, sums the assists field, and filters to the governed skill and the current period. The same aggregation grouped by department gives the team view.
Figure 5. The detection report, a bar report on the ledger grouped by user and summing assists for the period. One user stands well above the personal budget.
Step 4. Create the notifications
Define notifications for the warning bands at 50, 75 and 90 percent of budget, plus a pause notice and a restore notice. Send the warnings to the user and their lead. Write the final warning in plain language so the user knows exactly what happens at 100 percent. The pause notice should name the skill, the overage, the duration, and the path back.
Figure 6. A warning notification at 90 percent of budget, naming the skill and the consumption so far. On instances without outbound mail the records still generate, which is enough for testing.
Step 5. Create the workspace banner
Create a banner announcement on sys_ux_banner_announcement with a warning color and the suspension summary, then map it to the Unified Navigation configuration through sys_ux_m2m_banner_announcement. That placement puts the banner at the top of the shell agents actually work in rather than on an employee portal.
Figure 7. The banner announcement mapped to Unified Navigation, with a warning color and a display window set to the budget period.
Scope the banner to your Now Assist user population and set its start and end dates to the budget period. The Now Assist panel does not display a custom suspension reason on its own, so the email and this banner are the genuine awareness surface.
Step 6. Orchestrate with a scheduled job or Flow
A daily job reads the ledger totals, compares them to the budgets, and acts. Crossing a warning band sends the matching notification once. Crossing 100 percent removes the user's grant of the skill role, adds the user to the suspended group, generates the pause notice and the banner, and opens an approval for the manager with the reason in its journal.
Figure 8. The suspended-user group, the audit marker the job populates when a user crosses 100 percent.
Figure 9. The approval the job opens for the manager, carrying the reason in its journal with one-step Approve and Reject actions.
Approving the request restores everything in one step. A second monthly job restores all suspended users when the new period begins, so the system heals itself even if nobody acts.
Step 7. Validate before rollout
Prove the loop on a sub-production instance first. The ledger accepts inserted rows, so you can seed realistic consumption against the governed skill, run the job, and watch the full cycle from warning to suspension to restoration. Confirm the role withdrawal leaves every other Now Assist skill working, and confirm the approval restores access in one step.
Section 4 - Choosing an enforcement posture
Change the above flow based on how you want to handle enforcement:
|
Posture |
Behavior at breach |
Fits |
|
Advisory |
Warn and report only, no enforcement |
Early adoption, productivity-first cultures |
|
Soft suspension |
Pause the skill, restore automatically next period, manager may lift early |
Most organizations; recommended default |
|
Approval-gated |
Pause and hold until a manager approves restoration |
Cost-sensitive or compliance-driven environments |
|
Hard hold |
Pause until an administrator intervenes |
Repeat offenders and misuse |
The recommended default is the soft suspension. It mirrors how assist budgets actually behave, a finite allocation that renews each period, and it keeps a human in the loop without making the human a bottleneck.
Section 5 - Design Considerations
- Per-person suspension needs the role granted directly to users. If the skill rides a shared role you don't own, exclude the suspended group with an applicability condition instead. Don't rewrite the roles an out-of-box skill checks.
- Metering is batched off-instance. Executions don't write a billable row on the spot. Treat the ledger as the system of record and expect short lag.
- The ledger is append-only. Deletes are rejected. Filter by skill and period instead of cleaning rows, and exclude the table from clones.
- Three layers can each block a skill. The role gate, the seat entitlement, and model provisioning. Diagnose in that order.
- Report through the API, not the builder. The builder won't save reports on this table, but an API-created one displays fine. Aggregate with a group-by, since per-user filtered totals under-count here.
Section 6 - Conclusion
A reportable usage ledger and role-gated skill access are enough to close the loop from detection to enforcement to restoration. This acts on the specific team or person who exceeded the specific budget for the specific skill. It warns before it acts, explains itself when it acts, and undoes itself when the period turns over. An admin can put this together in an afternoon from roles, groups, a report, notifications, an approval, a banner, and a scheduled job, and every step leaves the audit trail the platform already keeps.
1 Comment