# People and message steps

> Send email, reply in inbox threads, notify members, request approvals, and look up users and groups from a workflow.

These steps reach people: by email, with a notification in SAPUGO, or by asking them to approve something. Others look up users and groups so later steps can use a name or an email address.

## Email

| Step | What it does |
| --- | --- |
| **Send Email** | Sends an email to the addresses you give it, with a subject and an HTML body, and optional cc and bcc. Use it for people outside SAPUGO, such as customers and suppliers. |
| **Reply to Email Thread** | Replies inside an existing shared inbox conversation. Use it when the workflow was started by an incoming email and the answer belongs in that thread. |
| **Break Email** | Splits an incoming email into its parts: sender, recipients, subject, body, attachments, and when it arrived. |

> **Note:** **Send Email** sends through your own outgoing email account, so messages come from your domain. Set one up first under **Settings**, **Developer Tools**, **Email**, with **New transport**. SMTP and several common sending services are supported.

To build the email body, use the **Template** value to fill placeholders with record values.

## Notifications in SAPUGO

Notifications appear in the person's inbox in SAPUGO and follow their notification preferences. Each can point at a record, so clicking the notification opens it.

| Step | Who receives it |
| --- | --- |
| **Notify Users** | Specific members. |
| **Notify Groups** | Every member of one or more [groups](/docs/groups). |
| **Notify Subscribers** | People who follow a table or a record. |

Each step returns how many people were notified.

## Approvals

**Request Approval** pauses the run and asks people or groups to decide.

1. Add **Request Approval** and give it a title and a message that explains the decision.
2. Pick the users, the groups, or both who can decide.
3. Optionally add questions for the approver to answer, and a timeout.
4. Optionally point it at the record the decision is about, so approvers can open it.
5. Connect what should happen to the **Approved**, **Rejected**, and **Timeout** paths.

The request appears on the **Approvals** page for each assignee, who can **Approve** or **Reject** and add a comment. The step outputs the decision, who decided, when, the comment, and any answers.

Put the writes that depend on the decision on the **Approved** path. Never wait for an approval inside a transaction.

## Users and groups

| Step | What it does |
| --- | --- |
| **Current User** | The person who started the run. It's empty when a schedule or another system started the run, so check its **found** output before using it. |
| **User from Id** | Loads a member from an ID, such as the value of a Person column. |
| **Group from Id** | Loads a group from an ID. |
| **Group Members** | Lists the active members of a group. |
| **Break User** | Splits a user into fields: name, email, whether they own the organization, their groups, and more. |
| **Break Group** | Splits a group into its ID, name, and description. |

## Checking what kind of value you have

| Step | What it does |
| --- | --- |
| **Is Class?** | Answers whether a value is of a given kind, such as a record, a file, or a user. |
| **Cast Object** | Continues on **Success** when a value is the expected kind, and on **Fail** when it isn't. |

## Plan your messages

For each message, say who receives it and whether it's an email or a notification in SAPUGO. For an approval, name who decides, the question, the timeout, and what each path does. A scheduled workflow has no current user, so name the person or group it should notify instead.

  - [Workflows](/docs/workflows): Triggers, runs, and approvals.
  - [Groups](/docs/groups): Organize members to notify and to approve.

---

Source: https://community.sapugo.app/docs/workflows/nodes/people