Using MemberArea steps in a flow

Once the app is connected, MemberArea shows up as its own category in the step catalogue of the flow builder. Every step is an action step: it runs, it answers, and the flow carries on with whatever it sent back.

How a step finds the right person

You never have to pass an id around. Each step receives the subscriber from ManyChat and looks the person up by the email address, first as a member, then as a contact. If that finds nobody, the step falls back to the link an earlier step created for this subscriber, and then to the phone number.

Events run the other way round. They start from a person in your memberarea and search for the matching subscriber. They first fill in the email address and phone number your memberarea knows, then try the link, the email address and the phone number in that order.

The first step that touches a person also remembers the connection, so everything after it lands on the same member without asking again. That is why Save contact in MemberArea or Find person in MemberArea makes a good first step in a flow: after it, the rest of the flow knows who it is talking to.

The steps

Finding and saving people

• Save contact in MemberArea: creates the contact or updates the existing one, and remembers which subscriber it belongs to.
• Find person in MemberArea: answers whether this subscriber is a member, a contact or unknown, so your flow can branch.
• Create member: creates the account. When the account is new, the step also hands back a login link that works without a password. The link is valid for 24 hours and works once. Someone who already had an account gets no link.

Tags, groups and fields

• Add tag and Remove tag: a tag can start an email sequence, an automation or a webhook in your memberarea, so this is often the only step a simple flow needs.
• Add to group and Remove from group: automatic system groups cannot be changed.
• Set member field: writes a value into one of your member fields, for example a birthday or a goal. A changed value starts the automations that listen for it.

Access and courses

• Grant access and Revoke access: gives or takes back everything that belongs to a product or a bundle. Granting creates the account if needed and writes no order. Revoking leaves the account in place and keeps whatever the person still has from another paid order.
• Enroll in course and Remove from course: only published courses can be picked, so the member always lands on real content. Removing keeps progress.
• Get course progress: reads how far the member got, so you can nudge exactly the people who stalled.

Selling and events

• Send checkout link: builds a personal checkout link with the email address already filled in.
• Get order status: reads the last order and the current subscription, ready to use in a message.
• Register for event: registers the person and answers with the local start time and the event link. With yes in Use the waiting list, a full event puts the person on its waiting list instead of refusing.

Everything else

• Start automation: starts one of your published automations for this person. Extra data reaches the automation as its input, as plain text or as JSON.
• Send member summary: answers with a finished message instead of single values. Membership state, course progress, last order and a login button, plus quick replies the subscriber can tap.

Dropdowns show your real data

Where a step needs one of your products, bundles, courses, groups, tags, fields, events or automations, the dialog offers a dropdown rather than a text field. ManyChat loads that list from your memberarea while the dialog is open, so you pick the real thing and cannot mistype an id.

Only items a step can really use are offered. A draft product, an unpublished course or an event that has already ended does not appear.

Using what a step sends back

Every step answers with named values, and ManyChat lets you map each one into a custom field. Get order status hands back the order number, the amount as a number and the same amount already formatted with its currency, so a message can say "Your order ORD-1042 over 49.00 EUR is paid" without any string juggling. Amounts follow the language of your memberarea, so a German memberarea writes 49,00 EUR. A price that does not include tax carries "plus VAT".

The same pattern holds everywhere: where money or a date is involved you get both the raw value and a ready-to-read version. The raw date is there to compare against, the readable one is already written out in the language and the time zone of your memberarea, so it belongs in the message.

When a step cannot do the job

Every step also sends back three values you can map like any other: Ok, Error code and Message. When the step did its job, Error code stays empty. When it could not, Error code holds a short code such as course_not_published, and Message holds a whole sentence: "This course is not published yet, so nobody can be enrolled. Please publish it in your MemberArea first." That sentence can go in front of a person as it is.

A condition step on Error code lets the flow take another path, for example sending the checkout link when access could not be granted. Problems with the connection itself, such as an invalid API key or a plan without the API, make the step fail in ManyChat instead. Fixing problems with the ManyChat connection explains each of those messages.

Branching on the person works the same way. Find person in MemberArea answers member, contact or none in its Found value, and a condition step on that value is usually the whole logic a sales flow needs.