16 July, 2026

This release adds finer-grained task permissions, built-in roles and teams for notifications and administration, and removes the API key requirement for flow AI steps on Keel-hosted environments.

Task permission actions

Task @permission rules now accept an actions argument that narrows a rule to one of two groups of task operations:

• manage covers the topic-wide operations: viewing a task topic's summary, statistics, and queue, creating tasks, and assigning, unassigning, cancelling, completing, or deferring them.
• run covers claiming and working a single task: next, pickup, and start, completing or deferring it, and reading a single task with its history.

task OrderReview {
    @permission(actions: [run], roles: [Support])
    @permission(actions: [manage], roles: [Admin])
}

A task @permission with no actions argument still governs every task action, so permissions you already have keep working unchanged. An unknown action name on a task @permission is now a schema error, caught when you build.

The tasks SDK (TaskAPI) now uses a full-access service token by default for server-to-server calls. Backend code that creates or manages tasks on a user's behalf, such as a function, job, subscriber, or flow step, is no longer blocked by that user's own topic permissions. The explicit user-scoped paths, withIdentity(...) and withAuthToken(...), are unchanged.

Built-in Notifications role and SuperAdmin team

When userProvisioning is enabled, two built-ins are now available:

• A Notifications role that grants access to the notifications API. Assign it through a team's roles.
• A SuperAdmin team whose members hold every role in your schema and bypass row-level @permission expressions.

Notifications and SuperAdmin are now reserved names. Declaring your own role called Notifications, or your own team called SuperAdmin, is a schema error.

Breaking change: in a project without teams or userProvisioning, calls to the notifications API made with a user access token now return 403. Notifications are service-token-only for user-facing calls. Previously any authenticated user could create, list, or read notifications, so client code that relied on that access needs to move those calls to backend code running under a service token.

For any issues or feedback, please contact us at help@keel.so.

Thank you for using Keel!