Notify Member Action

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 or email delivery, the target Member needs a valid contact method and the corresponding channel enabled in their notification preferences.

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 who receives the notification

Under Send To, nothing is selected until you choose. Pick one:

Specific Member: Choose a team member from the list. The notification always goes to this person, whichever patient or member the event is about. Use this for staff alerts — on-call staff, supervisors, or care coordinators.

The Member this event is about: The notification goes to the Member the event concerns. For a Journey or Workflow, that is the enrolled Member, who may be a patient. If the event has no Member of its own, it goes to the Member associated with whatever started the event. A record event for a record that has no owner is the exception: nothing is sent. Write the message for that person — never staff-only wording.

To alert staff, always choose a specific Member. "The Member this event is about" can be a patient.

Older setting: Actions created before this choice existed may show "Older setting: this notification goes to the Member associated with whatever started the event." That Member can be a patient on some events and a staff member on others. The action keeps working as it always has, but you must choose a recipient before you can save a change to it.

7. Write the notification message

In the Message field, enter the notification text. The field starts empty — there is no default message, because the right wording depends on who receives it. This is a template — you can use {{variable}} syntax to personalize the content. Variables describe the event (for example, {{member.name}} is the Member the event is about), whoever receives the notification:

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. The Developer CEL reference lists variables and functions by event context:

"high-priority" in member.labels && is_business_hours

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.last_name}}	"Smith"
{{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:

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:

Channel	Default	Notes
SMS	Enabled
Email	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 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}

Creating a Member Notify Action

POST /event-rules
Content-Type: application/json

{
  "objectType": "member",
  "eventType": "task:entered",
  "taskId": 123,
  "actionType": "member:notify",
  "actionParams": {
    "recipientMode": "specific_member",
    "memberId": 42,
    "messageTemplate": "Patient {{member.id}} has entered the escalation queue. Please review."
  },
  "name": "Notify coordinator on escalation",
  "active": true
}

Requires automations:admin scope.

actionParams fields for member:notify:

Field	Type	Required	Description
recipientMode	string	Yes, for new actions	specific_member sends to memberId. target_member sends to the Member the event is about (for a Journey or Workflow, the enrolled Member); if the event has no Member of its own, the Member associated with whatever started it; if there is none, or the event is for a record with no owner, nothing is sent.
memberId	integer	With specific_member	ID of the team member to notify. Not allowed with target_member.
messageTemplate	string	Yes	The notification message, not blank. Supports {{variable}} template syntax.
sendToOwner	boolean	No (older actions)	Older setting, still accepted: sends to the Member the event's execution runs as, which is not an owner lookup and can be a patient. Cannot be combined with recipientMode.

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 Actions.

List Member Notify Rules

GET /event-rules?actionType=member:notify

Requires automations:read scope.

Update a Rule

PUT /event-rules/{event_rule_id}
Content-Type: application/json

{
  "actionParams": {
    "recipientMode": "specific_member",
    "memberId": 42,
    "messageTemplate": "Updated: patient {{member.id}} needs review."
  }
}

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 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_event_member (the action sends to the Member the event is about, and this event had none), no_target_member (an older action with no recipient 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