notify

{{context}}

Help me set up or review notifications for this workflow.

• First read the current workflow configuration. Explain the current Gmail sender and recipients, other effective destinations, saved notification instructions, and whether the Slack webhook secret reference is healthy. Never reveal or write a webhook URL to workflow.json, prompts, logs, or ordinary files.
• Notifications are agentic: the agent decides when a non-blocking FYI, alert, progress update, or completion notice is useful and chooses the content. Delivery is deterministic: the agent calls notify_user and the backend automatically applies the workflow Slack webhook plus enabled account-level notification channels. Slack is rich Block Kit by default; for structured summaries set slack_title, factual slack_color, slack_fields, slack_sections, and slack_footer on that same call. Never access a SECRET_* webhook variable, post with curl, or disable automatic Slack delivery to avoid a duplicate. Do not add a routing step merely to choose a notification channel.
• Ask separately what the workflow run summary should contain and what the Pulse review summary should contain, and whether they should use different channels or go to different people. Store only explicit, durable user-approved preferences with update_workflow_config(run_notification_instructions="...", pulse_notification_instructions="...", run_notification_channels=[...], pulse_notification_channels=[...]). workflow.json notifications.run_summary_instructions, notifications.pulse_summary_instructions, notifications.run_summary_channels, and notifications.pulse_summary_channels are authoritative; never put notification preferences in soul/soul.md. If the user says a preference applies to every notification, save it in both matching fields. Do not store temporary choices or credentials there.
• To configure a workflow Slack Incoming Webhook, use list_secrets first. If I provide a new URL, store it with set_workflow_secret(name="SLACK_NOTIFICATION_WEBHOOK_URL", value=), then call update_workflow_config(slack_webhook_secret_name="SLACK_NOTIFICATION_WEBHOOK_URL"). The configuration tool validates the encrypted secret, makes it backend-only, and removes it from agent-visible secret injection. To disable workflow webhook delivery, call update_workflow_config(slack_webhook_secret_name="").
• SLACK CHANNELS: a Slack Incoming Webhook is tied to ONE channel when it is created and cannot be pointed at another, so "send this to a different channel" always means "use a different webhook". If I want the run summary and Pulse review in different channels, ask me for a webhook URL for EACH channel, store each under its own descriptive secret name with set_workflow_secret, then call update_workflow_config(run_notification_slack_webhooks=["SECRET_NAME_A"], pulse_notification_slack_webhooks=["SECRET_NAME_B"]). List several names to post one summary to several channels. Pass an empty array to fall back to the single workflow webhook. Never ask me to "pick a channel name" as if one webhook could reach several — tell me plainly that each channel needs its own webhook URL.
• Gmail is an inherited account-level notification channel. If I name who should receive this workflow's email, SAVE it — do not just use it for one send. Store it with update_workflow_config(run_notification_recipients=[...], pulse_notification_recipients=[...]); those persist to workflow.json notifications.run_summary_recipients / pulse_summary_recipients and the backend addresses every matching send from them automatically. Ask whether the run outcome and the Pulse review should go to the same people, since they are separate lists. Recipient lists say where mail GOES; they never unblock a blocked address, so if I name an address that is on a denylist, tell me rather than silently saving a list that will be skipped. Pass an empty array to clear a list back to the account default. Use the one-off email_to argument only for a single send I asked for explicitly.
• Gmail notification sender is one FROM account for this workflow's notify_user emails, including run and Pulse summaries. get_workflow_config shows the saved choice and enabled Gmail connection IDs. If I choose a sender, save its ID with update_workflow_config(notification_gmail_connection_id=""); pass an empty string to inherit the account default. This is the same Notify sender setting shown in the UI. Do not change recipients when changing sender. Ordinary workflow and Builder Gmail actions can still choose their own connection_id and recipients independently.
• If I asked to test delivery, call notify_user once with a clearly labeled test message and report its returned delivered/skipped/failed channels honestly. Do not send a test unless I requested one.
• human_feedback is separate: use it only for short-lived input that must block this run, such as OTP, CAPTCHA, or immediate approval.