Send Notification Action (Member Notify)

Notify team members automatically when workflow tasks are entered, forms are submitted, or other events occur.

Intermediate
10 min read

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 caseWhy Member Notify
Escalation alertsNotify a specific clinician or supervisor when a patient escalates to human review
Form submission follow-upAlert a care coordinator when a patient submits an intake form
Priority queue routingNotify the VIP team lead when a high-priority member enters a task
Scheduled check-insUse with a Routine to remind team members to follow up
Role-specific handoffTarget 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:

TriggerUse case
Task EnteredNotify when a member reaches a specific workflow step
Data Record CreatedNotify when a form is submitted
Data Record UpdatedNotify when a form field changes
Member UpdatedNotify 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_member error.

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:

VariableExample ValueNotes
{{member.first_name}}"Jane"
{{member.name}}"Jane Smith"
{{member.id}}42Safe to include in logs/messages
{{member.data.SLUG.FIELD}}Custom form dataReplace 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:

  1. The target member's notification preferences — which channels they have enabled (SMS, email, in-app)
  2. Their contact details — they must have a phone number for SMS, and an email address for email delivery

Default preferences for workspace members:

ChannelDefaultNotes
SMSEnabled
EmailDisabled
VoiceDisabledChannel toggle exists; voice call delivery is not yet implemented (planned for a future release).
In-appAlways

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 ActionNotification Rule
Configured inActions pageSettings → Escalation → Notification Rules
TriggerAny event type (task, form, message, etc.)AI escalation (tool.escalate) only
Message contentCustom templateSystem-generated (escalation context)
ConditionsCEL expressionsWorkflow scope only
Delay supportYesNo
Use forWorkflow-specific alerts, form notificationsGeneral 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:

FieldTypeRequiredDescription
messageTemplatestringYesThe notification message. Supports {{variable}} template syntax.
memberIdintegerConditionalID of the team member to notify. Required if sendToOwner is false.
sendToOwnerbooleanNoIf true, notify the member who triggered the event. Overrides memberId.

objectType values:

ValueTrigger scope
memberMember-level events (task entered, member updated)
data_recordForm events (record created, record updated)

eventType values for Member Notify:

ValueDescription
task:enteredMember enters a workflow task
task:exitedMember exits a workflow task
data_record:createdA form record is created
data_record:updatedA form record is updated
member:updatedA 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

ActionRequired Scope
View Member Notify actionsautomations:read
Create, edit, or delete Member Notify actionsautomations:admin
Update member notification preferencesmembers: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 (neither memberId nor sendToOwner was set).
  • 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