Where do GoWork scheduled-task notifications go?
In GoWork, a scheduled task is not the same thing as a notification target. Whether a result returns to the current conversation, appears in a global reminder list, or stays silent in the background depends on notify targets, query scope, and task type.
If you have used GoWork scheduled tasks for more than a few minutes, you will usually run into three questions: where does the result actually get delivered, why does “what reminders do I have?” often show a global list, and why should some tasks not notify anyone at all? The short answer is that task triggering, notification delivery, and list scope are three different layers.
That separation is one of the biggest differences between OmniGoAI's GoWork and a simple reminder app. GoWork does not just fire a message at a fixed time. It separates when a task runs, which conversation should receive the result, and whether the run should stay silent unless something important happens. Once those layers get mixed together, teams usually end up with noisy monitors, results delivered to the wrong place, or reminder lists that look “incorrect” even when the system is behaving as designed.
If you have already read Scheduled ops workflows with GoWork and Chat context vs runtime context for AI assistants, this article narrows the scope to one of the most common points of confusion: where do GoWork scheduled-task notifications really go, and why does scope often behave differently from what users expect?
The short answer: execution scope, notification scope, and list scope are different things
A simple mental model is this:
- The task itself answers: when does it trigger, and what does it do?
- The notification target answers: which conversation should receive the result?
- The list scope answers: are you viewing all active tasks, or only the ones bound to the current chat?
Many misunderstandings start when those three layers are treated as one.
For example, a user might say “remind me tomorrow morning about the meeting.” The system needs to create a future task, decide where the reminder should come back, and later answer “what reminders do I have?” with the user’s broader active-task set rather than only the one created in this chat. So a task can notify the current conversation by default while still appearing in a global reminder list. Those are not contradictory behaviors.
What actually decides where the result is delivered?
The direct factor is the notification target: which conversation or conversations should receive the run result.
Case 1: default delivery to the current conversation
This is the most common case. A user says things like:
- “remind me tonight at 8 to send the weekly report”;
- “remind me tomorrow at 9 to follow up with the client”;
- “every Monday at 10, remind me to review the schedule.”
If no alternative delivery target is specified, GoWork will usually bind the notification to the current conversation. That makes the interaction intuitive: the task is created here, and the result comes back here.
This is why many users naturally assume: if I created the reminder in this chat, it should come back to this chat. In most ordinary reminder cases, that expectation is correct. But it only describes the default delivery target. It does not mean the task is invisible to the rest of the system.
Case 2: explicit delivery to another conversation
Some tasks are configured in one place but meant to report results somewhere else. Common examples include:
- creating a daily summary task in a web session;
- sending the final summary into a DingTalk group;
- reporting monitor hits into a team room instead of the original setup chat.
In these cases, the creation surface and the delivery surface are different on purpose. The task may be configured here while the result is meant to land somewhere else.
Case 3: silent background execution
Some scheduled tasks should not notify anyone on every run at all, such as:
- background polling until a condition changes;
- periodic checks that only matter on failure or match;
- maintenance-style runs where the history matters more than live chat delivery.
These tasks can run with no notification targets. They still execute, and they still leave run history, but they do not push a message into a chat on every trigger.
That distinction matters because not every scheduled task should behave like a chat reminder. In an execution-oriented system, running and notifying are related but separable choices.
Why does “what reminders do I have?” usually return a global view?
Because in most cases the user is not asking “what belongs only to this chat?” They are asking “what active reminders or scheduled tasks do I currently have?”
If the system defaulted to the current conversation only, it would often hide tasks created in another chat, another channel, or another workflow.
That is why the more useful default is:
- global list: show the active reminders and tasks as a whole;
- current-conversation list: show only the tasks bound to this chat.
Neither is more “correct” in the abstract. They answer different questions.
Imagine this setup:
- one monitor task was created in a web session;
- one reminder was created in Telegram;
- one weekday summary runs into a DingTalk team room.
If the user later asks on the web, “what reminders do I have?”, returning only the web-bound task would feel incomplete. A global default is usually the better management view. The narrower conversation-only scope makes sense only when the user explicitly asks for it.
When should you use current conversation, explicit targets, or silent mode?
They correspond to different collaboration intents.
1. current conversation: best for personal reminders and local follow-through
Examples:
- “remind me tomorrow morning at 8 about the meeting”;
- “every evening at 6, remind me to send the daily update”;
- “in 30 minutes, remind me to come back to this task.”
The key property is simple: the result should come back to the same place where the user is already working.
2. explicit notification targets: best for team sync and cross-channel delivery
Examples:
- “every day at 9, send the inspection summary to the team room”;
- “when the page recovers, notify the on-call group”;
- “when this task finishes, send the result to the project conversation.”
Here, the key question is not where the task was created but where the output belongs.
3. silent execution: best for monitors, guards, and low-noise background work
Examples:
- check a status every 5 minutes, but only notify on a match;
- do a periodic aggregation in the background and surface only failures;
- keep run history for a maintenance task without pinging a human every time.
This is where many systems go wrong by notifying on every run. Silence is not failure. In many workflows it is the right default.
Why should monitors separate execution from notification especially carefully?
Because the point of a monitor is continuous observation, not continuous messaging.
For example:
- “check the page every 5 minutes and tell me if the price drops below 250”;
- “watch the publishing job and tell me once it reaches completed”;
- “look for new ERROR entries every 10 minutes and notify me only if new ones appear.”
If every polling run sends a message, the task becomes spam. If nothing is ever reported, users may assume it is not running. The stable pattern is usually:
- run in the background on schedule;
- keep normal runs in history;
- notify only on a meaningful hit or failure;
- cancel or finish the task once the monitored condition is satisfied.
That is why Scheduled ops workflows with GoWork keeps emphasizing that monitors are not “daily reminders.” They are “scheduled checks with selective delivery.”
Why do users often confuse current conversation and global scope?
Because humans think first in terms of “the chat I am looking at right now,” while the system often needs to organize tasks as “everything currently active for me.”
That mismatch creates three common false impressions.
Impression 1: if a task was created in this chat, it belongs only to this chat
Not necessarily. The notification may default to this conversation, but the task can still exist in the user’s global task set.
Impression 2: if I see tasks from elsewhere in the list, the system mixed conversations up
Often it did not. The user may simply be seeing the intended global view of active tasks across conversations.
Impression 3: if I was not notified, the task did not run
This is especially misleading for silent tasks. Some jobs are designed to leave run history and notify only on match, failure, or a meaningful conclusion.
A practical rule: when should you inspect the global list, and when should you stay in the current conversation?
A simple rule of thumb works well.
Prefer the global list when the user asks:
- “what reminders do I have?”
- “how many scheduled tasks are active?”
- “which reminders are still running?”
These are normally whole-account questions.
Prefer the current conversation only when the user explicitly asks:
- “what reminders are bound to this chat?”
- “which tasks belong to the current conversation?”
- “is the reminder we created here still active?”
Those are narrower, conversation-scoped questions.
The three most common mistakes in scheduled-task notification design
Mistake 1: notifying on every run by default
That turns monitors and background guards into noise generators.
Mistake 2: confusing query scope with delivery target
A global list is for inspection. A notification target is for delivery. They solve different problems.
Mistake 3: treating the creation surface and the delivery surface as the same thing
A task can be created on the web and report back into DingTalk. It can run inside a task sandbox and still auto-deliver into a user-visible conversation. Those are different layers and should stay separate.
FAQ
FAQ 1: If I create a reminder in the current chat, will it only exist inside this chat?
Not necessarily. Its default delivery target may be this conversation, but a global task listing can still show it alongside your other active reminders.
FAQ 2: Why do some scheduled tasks run without notifying me?
Because some tasks are intentionally silent. They execute in the background, keep run history, and notify only when a condition is met or something goes wrong.
FAQ 3: When should I specify notification targets explicitly instead of using the current conversation?
Whenever the result belongs in another team room, another channel, or a fixed project conversation rather than the chat where the task was configured.
FAQ 4: Why is “what reminders do I have?” not limited to the current conversation by default?
Because most users asking that question want an account-wide view of active reminders. Restricting the result to the current chat would often hide valid tasks and make the list less useful.
If you want to reason about scheduled-task delivery clearly, the key is to stop treating it as one flat reminder feature. Split it into triggering, delivery target, and silence vs notification. Once you do that, reports, monitors, follow-ups, and cross-channel workflows become much easier to design without mixing up scope and delivery. If you want to try it yourself, start from the GoWork download page, then pair it with the GoWork assistant docs to see how a scheduled task moves from trigger time to result delivery.