Send Notification Action (Member Notify)
Notify team members automatically when workflow tasks are entered, forms are submitted, or other events occur.
Creating a Member Notify Action on a Workflow Task
A Member Notify (Send Notification) action sends an in-app, SMS, or email notification to a specific team member when an event occurs in your workspace. Use it to alert staff to escalations, form submissions, task completions, and other workflow milestones that require human attention.
How it fits together: "Member Notify" is an Action type in Gravity Rail. Attach it to a workflow task as an entry action — when a member enters the task, the notification fires automatically. The notification is delivered on whichever channels the target team member has enabled in their notification preferences.
When to Use Member Notify
| Use case | Why Member Notify |
|---|---|
| Escalation alerts | Notify a specific clinician or supervisor when a patient escalates to human review |
| Form submission follow-up | Alert a care coordinator when a patient submits an intake form |
| Priority queue routing | Notify the VIP team lead when a high-priority member enters a task |
| Scheduled check-ins | Use with a Routine to remind team members to follow up |
| Role-specific handoff | Target a specific staff member by ID when a workflow reaches a handoff step |
Member Notify vs. Notification Rules: Notification rules are configured in workspace settings and fire automatically on escalation events (e.g., when the AI calls talk_to_human). Member Notify actions give you explicit, programmable control — you decide exactly which event, which condition, and which team member, and you compose the notification message yourself. Use notification rules for automatic escalation coverage; use Member Notify actions for workflow-specific or event-driven alerts.
Prerequisites
- A workflow with at least one task (see Workflows)
- The target team member must be a workspace member with a profile in Gravity Rail
- For SMS delivery, the target member must have a phone number set and notify_sms enabled (on by default)
- For email delivery, the target member must have notify_email enabled (off by default)
Steps
1. Open your workflow
Navigate to Workflows and open the workflow you will use. If you don't have one yet, create a new workflow and add at least one task.
2. Navigate to the Actions page
Go to Actions in your workspace.
3. Create a new action
Click New Action.
4. Configure the trigger
Set the trigger to match the event that should fire the notification. Common triggers:
| Trigger | Use case |
|---|---|
| Task Entered | Notify when a member reaches a specific workflow step |
| Data Record Created | Notify when a form is submitted |
| Data Record Updated | Notify when a form field changes |
| Member Updated | Notify when a member's profile changes |
Select the specific task, data type, or workflow relevant to your trigger.
5. Select "Member Notify" as the action type
In the action type dropdown, select Member Notify. The notification configuration form will appear.
6. Choose the notification target
You must specify who receives the notification. Two options are available:
Option A — Notify a specific member: Select a team member from the Member dropdown. The notification is always sent to this person, regardless of which patient or member triggered the event. Use this for dedicated on-call staff, supervisors, or care coordinators.
Option B — Notify the triggering member's owner: Enable Send to owner. When this is on, the notification is sent to the member who triggered the event (the "triggering member") rather than a fixed team member. Use this for self-directed reminders or when the workflow assigns an owner dynamically.
Note: One of these must be set. If neither is configured, the action will fail with a
no_target_membererror.
7. Write the notification message
In the Message field, enter the notification text. This is a template — you can use {{variable}} syntax to personalize the content:
Hi {{member.name}}, a patient has submitted their intake form and is waiting in the queue.
The message is rendered using the same template system as other action types. See Template Variables below.
8. Optionally add conditions
If you want the notification to fire only under certain conditions (e.g., only during business hours, or only for VIP members), add a CEL expression in the Conditions field:
cel
Leave the conditions blank to fire on every matching event.
9. Optionally set a delay
If you want the notification to fire after a delay (e.g., escalate only if no response in 2 hours), enable the delay option and set the duration in hours, minutes, or seconds.
10. Save the action
Click Save. The action is now active and will fire when the trigger conditions are met.
Template Variables
Use {{variable}} syntax to personalize notification messages:
| Variable | Example Value | Notes |
|---|---|---|
{{member.first_name}} | "Jane" | |
{{member.name}} | "Jane Smith" | |
{{member.id}} | 42 | Safe to include in logs/messages |
{{member.data.SLUG.FIELD}} | Custom form data | Replace SLUG with your data type slug |
{{task.name}} | "Intake Review" | |
{{assistant.name}} | "Care Bot" |
Healthcare compliance note: Avoid including PHI (patient names, health details, phone numbers) in notification messages that may be delivered via SMS or email. Use member IDs and task names instead, and link recipients back to the Gravity Rail app for full context.
For the full list of available variables, see Template Variables.
Notification Delivery
The notification is delivered on channels based on two factors:
- The target member's notification preferences — which channels they have enabled (SMS, email, in-app)
- Their contact details — they must have a phone number for SMS, and an email address for email delivery
Default preferences for workspace members:
| Channel | Default | Notes |
|---|---|---|
| SMS | Enabled | |
| Disabled | ||
| Voice | Disabled | Channel toggle exists; voice call delivery is not yet implemented (planned for a future release). |
| In-app | Always |
Members can be updated individually in People → Members → Edit → Notifications, or in bulk via CSV import. See Notification Preferences.
If a channel is disabled or contact details are missing, delivery on that channel is silently skipped. In-app notifications are always delivered.
Example Scenarios
Escalation alert on task entry
Scenario: Notify the on-call coordinator when a patient enters the "Escalation" task.
- Trigger: Task Entered → "Escalation" task
- Target member: On-call coordinator (specific member ID)
- Message:
A patient needs immediate attention. Review the conversation in Gravity Rail: {{member.name}} (ID: {{member.id}}) - Condition: (none — all escalations notify)
Form submission follow-up
Scenario: Notify a care coordinator when a patient submits an intake form.
- Trigger: Data Record Created → "Intake Form" data type
- Target member: Assigned care coordinator (specific member ID)
- Message:
New intake form submitted. Member ID: {{member.id}}. Review in Gravity Rail. - Condition: (none)
High-priority escalation with delay
Scenario: Notify a supervisor if no response after 30 minutes.
- Trigger: Task Entered → "Awaiting Response" task
- Target member: Supervisor
- Message:
No response in 30 minutes for member {{member.id}}. Please review. - Delay: 30 minutes
Business-hours-only alert
Scenario: Only notify staff during business hours; after-hours escalations are handled separately.
- Trigger: Task Entered → "Escalation" task
- Target member: Day-shift lead
- Message:
Escalation received for member {{member.id}}. - Condition:
is_business_hours
Member Notify vs. Notification Rules
| Member Notify Action | Notification Rule | |
|---|---|---|
| Configured in | Actions page | Settings → Escalation → Notification Rules |
| Trigger | Any event type (task, form, message, etc.) | AI escalation (tool.escalate) only |
| Message content | Custom template | System-generated (escalation context) |
| Conditions | CEL expressions | Workflow scope only |
| Delay support | Yes | No |
| Use for | Workflow-specific alerts, form notifications | General escalation coverage |
Use both together: set up notification rules as a safety net for all AI escalations, and add Member Notify actions for specific workflow steps that need targeted, customized alerts.
API Reference
Member Notify actions are created via the Event Rules API.
Base URL: https://api.gravityrail.com/api/v2/w/{workspace_uuid}
Create a Member Notify Action
bash
Requires automations:admin scope.
actionParams fields for member:notify:
| Field | Type | Required | Description |
|---|---|---|---|
messageTemplate | string | Yes | The notification message. Supports {{variable}} template syntax. |
memberId | integer | Conditional | ID of the team member to notify. Required if sendToOwner is false. |
sendToOwner | boolean | No | If true, notify the member who triggered the event. Overrides memberId. |
objectType values:
| Value | Trigger scope |
|---|---|
member | Member-level events (task entered, member updated) |
data_record | Form events (record created, record updated) |
eventType values for Member Notify:
| Value | Description |
|---|---|
task:entered | Member enters a workflow task |
task:exited | Member exits a workflow task |
data_record:created | A form record is created |
data_record:updated | A form record is updated |
member:updated | A member's profile is updated |
For the full Event Rules feature reference, see Event Rules.
List Member Notify Rules
bash
Requires automations:read scope.
Update a Rule
bash
Requires automations:admin scope.
Permissions
| Action | Required Scope |
|---|---|
| View Member Notify actions | automations:read |
| Create, edit, or delete Member Notify actions | automations:admin |
| Update member notification preferences | members:write |
Tips
- Use member IDs in messages, not names — Member names are PHI in healthcare contexts. Referencing
{{member.id}}and linking to the app keeps messages compliant. - Check preferences before go-live — If a team member has SMS disabled, they won't receive SMS notifications. Verify preferences in People → Members → Edit → Notifications before relying on a new rule.
- Combine with conditions for precision — Add CEL conditions to avoid notification fatigue. For example, only notify for high-priority members or during staffed hours.
- Use delay for escalation ladders — Chain multiple Member Notify actions with increasing delays to escalate through a chain of contacts (5 min → coordinator, 15 min → supervisor, 30 min → manager).
- Test with a test member — Create a test member with your own phone number and email, then run a test conversation to verify the notification fires correctly before enabling for real members.
- Check action logs — Failed actions appear in the action execution log with an error code. Common errors:
target_member_not_found(member ID is wrong or the member was deleted),no_target_member(neithermemberIdnorsendToOwnerwas set).
Related
- Notifications — Configure escalation-based notification rules and understand how delivery channels work
- Notification Preferences — Per-member SMS, email, and voice opt-in settings
- Actions — Full list of action types and how to build event-driven automations
- CEL Expressions — Write conditions to control when actions fire
- Routines — Schedule automations to run on a recurring basis
- Template Variables — Full variable reference for personalizing messages
Related Resources
Workflows
Build AI-powered conversation flows with tasks, abilities, and agents.
Actions
Automate your workspace with event-triggered actions, notifications, and webhooks.
Experiments (A/B Testing)
Run member-level A/B tests with weighted groups, CEL branching, and journey goal reporting.
All Guides
Browse all available guides