[mngr]

Depends on cubedevinc/cubejs-enterprise#16532 (and its base cubedevinc/cubejs-enterprise#16531): do not merge before them. Also merge it together with, or after, the cube-js/cube API reference sync for the first @cube-dev/platform-client release that carries notification (cubedevinc/cubejs-enterprise#16532 adds the field and rewrites the condition descriptions in packages/platform-client/src/schema.ts): until that sync, docs-mintlify/api-reference/api.yaml has no notification field and still says the creator gets an inbox row only with notificationEnabled: true, which this page's Platform API section contradicts.

Summary

A scheduled task now notifies chosen people, user groups and Slack channels, by Inbox, Email and Slack together, instead of only its creator in the inbox. Rebased on master after #12283 (CUB-5559: list columns, Next run, Last check), #12307 (the Manage all scheduled tasks permission), #12309 (the task's Agent) and #12368 (data-model access in scheduled runs, a section this PR does not touch); their merged wording is the base. This PR updates:

• docs-mintlify/docs/explore-analyze/scheduled-tasks.mdx
  • Where to find it: the list's Notifications column now says where a task's notifications go ("Inbox, Email · 3 people, 1 group · #sales, #finance-alerts", or "Nobody is notified"), and links the renamed section.
  • Anatomy of a task: the Notify me when a run finishes toggle becomes the Notify section.
  • Conditional tasks: recipients other than the creator, and Slack, are told the condition started to hold without the figures. A task with a condition must notify someone: the dialog's Create (or, when editing, Update) button stays disabled and says why, the agent refuses, and the Platform API refuses when the request sets notification (a request without that field is saved, as before).
  • Managing tasks: anyone the task is shared with can open its runs' threads, view-only (previously: sharing the task did not share its threads).
  • Task detail page: a Notifies line, as in the list's column.
  • Last check: the example of a task that notifies nobody is one created through the Platform API without a notification field.
  • Getting notified when a run finishes is rewritten as Notifying people when a run finishes: people and groups (expanded when the run finishes, one message per person), Send by Inbox / Email / Slack (Inbox and Email go to everyone picked; one or more Slack channels), the creator picked by default, what each notification carries, sharing on save of a new pick (dialog, agent and Platform API alike), who a run reaches (the creator, plus people who can open the task and read its deployment), and the two ways a picked person is skipped and marked Not shared: won't be notified (their share was removed in the Share dialog, or they can't read the deployment), notifications going to recipients whoever runs the task, email unsubscribe, a failed run reaching only the creator, and the agent and Platform API.
  • The agent paragraph of that section: channels belong to the whole task, so asking the agent to notify one more person by inbox turns Inbox on for everyone the task notifies, and the agent says so.
  • Managing tasks from chat and with the Platform API: the new notification field and its caps; notificationEnabled deprecated.
• docs-mintlify/docs/inbox.mdx: the Scheduled task run row's "Who gets it", the figures shown only in the creator's notification, email/Slack from a task, and the anchor rename.

Verified against the code (feature branch HEAD e22eb3290b)

• Labels are the en-US keys in packages/console-ui/src/i18n/locales/en-US/scheduledTasks.json: notifyLabel "Notify", notifyRecipientsLabel "People and groups", notifyChannelsLabel "Send by", notifyRecipientNotShared "Not shared: won't be notified", notifySlackChannelsDescription "Slack posts once to each channel. Inbox and Email go to the people above.", summary.notifiesNobody "Nobody is notified", detail.notifies "Notifies".
• The list's Notifications cell and the detail page's Notifies line both render useNotificationSummary (task-notification.ts; ScheduledTaskListCells.tsx, ScheduledTaskInstructions.tsx); Inbox drops out of it when the workspace's inbox is off (deliveredNotification). The hand-off walk on staging-mngr-7 read "Inbox, Email · 4 people, 1 group" and "Inbox · 3 people, 1 group".
• The list's Last check reads "notified" when a crossing reaches anyone, not only the creator (taskOutcome(check, notifiesAnyone)).
• The condition rule: ScheduledTaskService.assertConditionNotifies holds a save only when it sends notification (sendsNotification) or the agent's update asks for it; the agent's create tool always sends notification (CreateScheduledTaskToolFactory.ts:112).
• Who a run reaches: AiEngineerController.notifyScheduledTaskRecipients expands groups at send time, de-duplicates, keeps only the creator on a failed run, and skips any non-creator for whom AiEngineerService.canViewScheduledTask (a ScheduledTask read grant or admin, plus deployment read) is false; Inbox is sent only with the tenant's useNotificationInbox on.
• Caps: NOTIFICATION_CAPS = { userIds: 1000, groupIds: 200, slackChannels: 50 } (packages/ai-engineer/src/dto/scheduled-task.ts:290).
• Sharing on pick: ScheduledTaskService.grantRecipientShares runs on every create and update (the dialog, the agent's createTask/updateTask tools and the REST controller all call the service), sharing only recipients the save ADDS and only if not already shared, so a share revoked in the Share dialog is not restored by a later save. The "Not shared" mark for a user is recipientUserIdsWithoutAccess, console-server's findUsersWithoutScheduledTaskAccess = canViewScheduledTask (task read grant or admin, AND deployment read), so a shared user who cannot read the deployment is marked too (PLAN AC-7d); a group is marked when it has no group grant and no organisation grant.
• Channels are task-wide on the agent's path too: NOTIFY_ARGUMENTS_DESCRIPTION (packages/ai-engineer/src/services/langgraph/tools/scheduled-task-recipients.ts:29, "for the whole task") and the update tool's channelsChanged note (channelChangeNote, same file, "Channels are shared by everyone this task notifies … Tell the user."). The r3 hand-off walk on staging-mngr-7 asked the agent to also notify a second person in the inbox on an Email-only task: the stored channels became Inbox + Email for both, and the agent's reply said so.
• The two feature commits since the last docs pass (7e097cebb6 Slack picker error handling, 1257d35839 a failed task email answers 503) change nothing the pages describe.
• The task dialog's submit button reads dialog.submitCreate "Create" on a new task and dialog.submitUpdate "Update" when editing (ScheduledTaskDialog.tsx:203); the r4 hand-off walk on staging-mngr-7 read "Create disabled" with the red line and Create's tooltip conditionNeedsNotification. The page used to call it Save; it now names both.
• The feature commits since the last docs pass (8904d17d1e keeps the dialog's 12 px field gap around the condition switch and the Notify section, which Igor flagged after the hand-off; the Slack OAuth listener refactor 773666a9d9/baed62646a; 50546100b7 drops a removed kit prop; e149367c86 a failed task email answers 503) change no behaviour the pages describe. The hand-off, re-posted for the spacing fix, says nothing else changed.
• A new task in the dialog starts with the creator picked and Inbox on; a task created by the agent or the API without a notification notifies nobody.

Feature PR: https://github.com/cubedevinc/cubejs-enterprise/pull/16532
Linear: https://linear.app/cube-d3/issue/CUB-5670/notify-other-people-about-scheduled-task-runs

[mintlify]

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

Project	Status	Preview	Updated
cubed3	🟢 Ready	View Preview	Oct 23, 2026, 2:27 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[claude]

Claude finished @mngr's task in 1m 21s —— View job

---

Small fixes needed: 1 medium, 2 low. One example contradicts the page, and the API reference won't show the new notification field until the spec is regenerated.

Review details

• Read diff and the full changed files
• Check anchors and links across docs
• Review content consistency
• Resolve stale threads
• Post review

Findings

Medium: scheduled-tasks.mdx:229-231 uses an example that contradicts the page (inline). It gives "one created through the Platform API's deprecated notificationEnabled field" as an example of a task that notifies nobody. But writing notificationEnabled: true adds the creator as a recipient (:357). The real way to get a silent task is to create it with the agent or the API without a notification (:300).

Low: scheduled-tasks.mdx:276 mentions past behaviour (inline). "so it notifies you the way it did before" describes how the product used to work. That doesn't belong in reference docs.

Low: the generated API reference is still on the old model (not inline). docs-mintlify/api-reference/api.yaml has no notification / userIds / groupIds / slackChannels and doesn't mark notificationEnabled deprecated. Its condition description (api.yaml:9291-9292, and the same text at :15985 and :17170) still says "The creator gets an inbox row only with notificationEnabled: true". The link at scheduled-tasks.mdx:362 says the API reference covers the fields, so it will contradict this page until the spec and changelog.mdx are regenerated from the feature PR's platform client. These files are generated, so they shouldn't be edited by hand here. Either land that sync with this PR or follow it closely.

Checked and fine

• No remaining links to #getting-notified-when-a-run-finishes or mentions of "Notify me when a run finishes" anywhere in docs-mintlify. The inbox.mdx ref-link is updated.
• The failed-run rule is consistent between scheduled-tasks.mdx:293-295 and the inbox.mdx:43 table row: only the creator is notified, if they're a recipient, on Inbox/Email only, never Slack.
• The rule that only the creator sees the condition figures is consistent between scheduled-tasks.mdx:104-106 and inbox.mdx:63-64.
• The thread-access change (:168-170) matches the view-only sharing described at :149-153.

Review threads

The listing returned 0 of my own threads, so there was nothing to resolve or re-affirm. Both inline findings were posted as new threads.

[claude]

Claude finished @mngr's task in 1m 11s —— View job

---

Review: no blockers. Found 1 medium and 3 low issues (all in scheduled-tasks.mdx).

Details

• Read diff
• Check links/anchors and full-file context
• Review threads
• Post review

Findings (posted inline)

Severity	Location	Issue
Medium	docs-mintlify/docs/explore-analyze/scheduled-tasks.mdx:141	The page says figures are hidden from non-creators "because the check read them with the creator's data access". The same page says those people can open the run thread, which starts with the value read (lines 132–134 and 210–212). It also says notifications and Slack posts carry the agent's answer, which was computed with the creator's access (lines 333–335). Either say what's hidden from them, or drop the rationale.
Low	scheduled-tasks.mdx:329	"the way it did before" describes the change, not the product.
Low	scheduled-tasks.mdx:418	The deprecated notificationEnabled is vague: "writing it adds or removes that" doesn't say what changes in notification. It's also unclear how it interacts with the condition rule. api-reference/api.yaml still says condition needs notificationEnabled: true and has no notification field. That stays wrong until the next platform-client sync.
Low	scheduled-tasks.mdx:340	Picking someone shares the task with them, so the page should say how a picked person can still be marked Not shared: won't be notified.

Checked, no issues

• No links to the old #getting-notified-when-a-run-finishes anchor or the Notify me when a run finishes label are left anywhere in docs-mintlify. The inbox.mdx link reference points to the new anchor.
• The Inbox row for Scheduled task run and the new email/Slack sentence match scheduled-tasks.mdx.

Not verified

I couldn't check the labels, caps (1,000 / 200 / 50) or recipient rules against the code: it lives in cubedevinc/cubejs-enterprise, which this checkout doesn't include. The review relies on the PR description for those.

Review threads

The thread listing returned 0 of my own threads, so I resolved none and re-affirmed none.

[claude]

Claude finished @mngr's task in 1m 25s —— View job

---

Review of PR #12266: 2 medium, 1 low. The docs match the code the PR description cites. The issues are that the page contradicts itself in one place and that the linked API reference is out of date.

Details

• Read the diff and changed files
• Review docs for accuracy and consistency
• Reconcile prior review threads
• Post review

Findings

Medium

• docs-mintlify/docs/explore-analyze/scheduled-tasks.mdx:337 says picking someone shares the task with them. Lines 339–342 then say a picked person who can't open the task is skipped and marked Not shared: won't be notified. The page never explains how a picked person ends up unshared: a share removed in the Share dialog, a Platform API userIds entry, or no read access to the deployment. Please name those cases. (inline)
• docs-mintlify/docs/explore-analyze/scheduled-tasks.mdx:418: the page now documents notification and deprecates notificationEnabled. The API reference it links to (api-reference/api.yaml) still has no notification field. Its condition descriptions (api.yaml:9440, :16189, :17382) still say the creator gets an inbox row only with notificationEnabled: true. If the platform-client sync is a separate PR, please note in the description that the two should merge together. (inline)

Low (not posted inline)

• docs-mintlify/docs/explore-analyze/scheduled-tasks.mdx:141–144: each Slack channel gets the condition-met post with a link to the run. Channel members may not be shared on the task, though. "The figures stay in the run's chat thread, which everyone the task is shared with can open" doesn't say what the link does for them.

Checked and fine

• No links to the old #getting-notified-when-a-run-finishes anchor and no mentions of the Notify me when a run finishes label are left anywhere under docs-mintlify/. inbox.mdx points to the new anchor.
• The failed-run rule ("only the creator, if a recipient") reads the same in scheduled-tasks.mdx:353 and in the inbox.mdx table row.
• The rule that a conditional task must notify someone (:146–150) agrees with the Last check example (:281), which is a Platform API task without notification.

Review threads

The listing returned 0 of my own threads: no prior threads, so none were resolved or re-affirmed.

[claude]

Claude finished @mngr's task in 1m 4s —— View job

---

Review: 0 high, 1 medium, 2 low. inbox.mdx says only the creator sees a conditional run's figures, which contradicts the scheduled-tasks page.

Details

• Read the diff and the changed files in full
• Check anchors, links and consistency between the two pages
• Review threads
• Post review

Medium

• docs-mintlify/docs/inbox.mdx:63 says "Only the task's creator sees the figures". scheduled-tasks.mdx:141-144 says the figures stay in the run's chat thread, and everyone the task is shared with can open that thread. Picking a recipient shares the task with them, so every recipient can see the figures. A creator reading the inbox page would wrongly think the figures stay private. Posted inline with a suggestion that limits the claim to the notification.

Low (not posted inline)

• scheduled-tasks.mdx:335 says each Slack post carries a link that opens the run. Slack channels are not shared the task, so the link opens only for channel members who can already open the task. A short note would set expectations.
• scheduled-tasks.mdx:364 says "A task that you create with the agent … notifies nobody, unless you ask for it". That doesn't hold for a conditional task, where the agent refuses a save that notifies nobody (as the Conditional tasks section says). The Last check example already uses only the Platform API case, which is right.

Checked, no issue

• Nothing in docs-mintlify still links the old #getting-notified-when-a-run-finishes anchor or uses the Notify me when a run finishes label.
• api-reference/api.yaml still describes the conditional rule as "only with notificationEnabled: true" and has no notification field. The PR description already lists this as a merge dependency on the platform-client sync.
• The failed-run rule (only the creator, if they are a recipient, by Inbox and Email) matches between scheduled-tasks.mdx and the Inbox table.

Review threads

The listing returned 0 of my own threads, so I resolved none and re-affirmed none.

[claude]

Claude finished @mngr's task in 44s —— View job

---

No issues found: 0 high, 0 medium, 0 low.

Review details

• Read the diff and changed files
• Check anchors and links
• Review threads
• Post review

What I checked

• Anchors: nothing in docs-mintlify (outside the generated api-reference/) still links to #getting-notified-when-a-run-finishes or mentions Notify me when a run finishes. The new #notifying-people-when-a-run-finishes anchor matches its heading, and docs-mintlify/docs/inbox.mdx:102 points to it.

• Consistency across the two pages: they agree on four points:

  • who a run reaches: the creator, plus recipients who can open the task and read its deployment
  • a failed run reaches only the creator
  • only the creator's notification carries the figures
  • Inbox is dropped while the workspace's inbox is off

  These are at scheduled-tasks.mdx:132-150, scheduled-tasks.mdx:313-368 and inbox.mdx:43, inbox.mdx:63-64.

• Earlier fixes are in place:

  • The Last check example now uses a Platform API task with no notification field (scheduled-tasks.mdx:281).
  • The condition rule spells out what each path does: the dialog, the agent, and the API with or without notification (scheduled-tasks.mdx:146-150).
  • The two ways someone gets the Not shared mark are named (scheduled-tasks.mdx:343-347).

• Merge ordering: the PR description says to merge with or after the api.yaml sync that adds notification. Until then, the Platform API paragraph (scheduled-tasks.mdx:416-423) contradicts the generated reference. That's expected, and this PR doesn't need a change for it.

Review threads

No prior threads: the listing returned 0 of my own unresolved threads. I resolved 0 and re-affirmed 0.

[claude]

Claude finished @mngr's task in 44s —— View job

---

No issues found in this round: 0 high, 0 medium, 0 low.

Review details

• Gather context
• Read changed files
• Check prior review threads
• Post review

Scope

This push adds one commit, 269f7b7. At docs-mintlify/docs/explore-analyze/scheduled-tasks.mdx:377-380 it says channels apply to the whole task: if you ask the agent to notify one more person by inbox, Inbox turns on for everyone the task notifies. This matches the dialog's model, where Send by applies to everyone picked (:332-334). It does not contradict the Platform API paragraph (:428-435) or the Inbox page.

I re-read both changed files in full, not just the diff:

• Anchors: no links to the old #getting-notified-when-a-run-finishes anchor or the old Notify me when a run finishes label remain outside the generated api.yaml. inbox.mdx points at the new anchor.

• Consistency across sections:

  • The conditional figures: :151-154 matches inbox.mdx:63-64.
  • The failed run reaching only the creator: :367-369 matches the Inbox table row.
  • Thread access for people the task is shared with: :219-223 matches :152-154.
  • The "Not shared" mark: :352-357.

  All of these agree.

• The dependency on the generated api.yaml sync is already in the PR description, so this page needs no change for it.

I couldn't check the agent's channel behaviour against cubedevinc/cubejs-enterprise#16532 from this checkout. The new sentence relies on the PR author's verification.

Review threads

The listing returned 0 unresolved threads of mine, so there was nothing to resolve or re-affirm.

[claude]

Claude finished @mngr's task in 49s —— View job

---

No new findings: 0 high, 0 medium, 0 low. Ready to merge once its dependencies have merged.

Review details

• Read the diff and the changed files
• Check anchors and links
• Review threads
• Post review

Scope

This round reviewed the docs-only diff in docs-mintlify/docs/explore-analyze/scheduled-tasks.mdx and docs-mintlify/docs/inbox.mdx. It covers the six commits up to 626a5a9.

Checks

• Anchors: no page in docs-mintlify/ still links #getting-notified-when-a-run-finishes. inbox.mdx:102 ([ref-scheduled-task-notifications]) now points at #notifying-people-when-a-run-finishes, which exists at scheduled-tasks.mdx:324.
• Old toggle name: nothing in the docs still says Notify me when a run finishes.
• Consistency: the two pages agree on each point below.
  • Figures on a conditional task: only the creator's notification carries them (scheduled-tasks.mdx:146-153, inbox.mdx:63-64). Everyone the task is shared with can open the run's thread, view-only (scheduled-tasks.mdx:221-224).
  • Inbox row "Who gets it": inbox.mdx:43 matches the access rule at scheduled-tasks.mdx:351-358 and the failed-run rule at :368-370.
  • Last check example: the example at :291-293 (a task created through the API without notification) matches the save rule at :156-161.
• API reference: docs-mintlify/api-reference/api.yaml (lines 9559, 16308, 17520) and api-reference/changelog.mdx:86 still describe notificationEnabled as the only switch. The PR description already makes merging wait for the @cube-dev/platform-client sync, so this round raises no finding for it.
• User-facing docs requirement: met. This PR is the docs.

Review threads

The listing returned 0 of my own unresolved threads, so this round resolved none and re-affirmed none.