Frequently Asked Questions

When you send a text or email to a cast member, understudy, or volunteer, you're asking for their attention and using a channel they may not want used for every purpose. "Consent" means they've indicated — or you've recorded on their behalf — that they're okay with being contacted on that channel, for that type of message.

MainPlank tracks consent because:

• Text messages (SMS) have legal teeth. In the US, sending marketing texts to someone who hasn't explicitly said yes is a violation of federal law (the TCPA). Even for operational messages, implied consent has limits.
• People trust you with their contact info. A paper trail protects both parties: it shows you acted in good faith, and it gives the person a way to verify what they agreed to.
• Multiple orgs share the same platform. A person might be in your cast list and another company's. Their choice to stop receiving texts from you shouldn't affect the other company — and vice versa, unless they want a full platform opt-out.

It means a specific, explicit record exists saying this person is okay with receiving texts. "Explicit" here means a human made an affirmative choice — either the person themselves flipped a switch in their own account, or a staff member checked a box on their behalf.

Implicit signals — like a person replying to an email, or being imported from a spreadsheet — do not count as SMS consent. Texts require a higher bar than email, by design and by law.

If someone texts STOP in response to a message, that instruction doesn't mean "stop texting me from this company." It means "stop texting me." Carrier networks (Twilio, etc.) enforce this at the phone-number level — once a STOP is received, no message from your sending number gets through to that phone, regardless of which org sent it.

Because the hard floor is platform-wide, the consent record follows the same shape. One revocation blocks all orgs. One explicit opt-in grants all orgs access (unless a specific org is later blocked — see the resolution hierarchy).

When someone replies STOP to a text, Twilio adds their number to a suppression list. Even if MainPlank's database says they're opted in, Twilio will silently drop the message.

A Twilio webhook (/api/sms/webhook) is live: a STOP reply automatically writes a Tier-2 opt-out, and a START reply clears it, keeping MainPlank and Twilio in sync — no manual step needed in the normal case. By deliberate design the webhook only flips the relationship/promotional opt-out; it does not silence transactional admin messages. You'd still record a revocation by hand only if someone tells you verbally rather than texting STOP.

No. Our privacy policy states: "No mobile information will be shared with third parties or affiliates for marketing or promotional purposes. Text messaging originator opt-in data and consent will not be shared with any third parties."

The only parties who ever see a mobile number are the service providers that physically deliver the message (e.g. Twilio for SMS), and only to send the message that was requested. This clause is what carrier vetting (A2P 10DLC, error 30908) checks for, and it lives at /privacy §4.

Yes — this is built but not yet switched on. Today every org sends from one shared MainPlank number, which is why a STOP is platform-wide. As MainPlank registers each org for business texting under its own brand (A2P 10DLC), each org will get its own dedicated sending number.

At that point a STOP sent to one theatre's number will be scoped to that theatre — opting out of one company won't silence the others.

Email consent in MainPlank is org-scoped — each organization manages its own relationship. Riverview Theatre can have consent to email someone even if Lakeside Rep has been blocked by that same person.

Email consent also has two types (scopes):

• Transactional — messages about something the person is already part of: "Rehearsal moved to Thursday," "Your contract is ready to sign," "Call time change."
• Marketing — outreach, news, and promotion: season announcements, donor appeals, newsletter, show promos.

A person can consent to transactional email only — meaning you can send them schedule changes but not newsletters. The scope is recorded with each consent entry.

Email doesn't go through a carrier network the same way SMS does. A person can have one email address but get messages from ten different companies, each with its own unsubscribe link. That's a normal email experience.

So each org-person relationship gets its own consent record, and revoking one doesn't affect the others.

Every consent entry has a source field that says how the consent came to be:

• explicit_staff — A staff member recorded consent on behalf of the person — for example, checking an "SMS OK" box while entering someone's info after they signed a paper form.
• explicit_self — The person logged into their own MainPlank account and toggled their own preferences. This is the strongest form of consent.
• import — The person was added via a bulk spreadsheet import. Records a weak transactional-email-only consent. SMS consent is never granted by import alone.
• transactional_reply — The person replied to a transactional email. Records a transactional email grant for that org only. Does not extend to marketing, and does not grant SMS.
• platform_signup — The person created their own MainPlank account. Records a platform-wide transactional-communications grant only.

The short version: if the source is explicit_staff or explicit_self, that's the strongest kind. The others are weaker and cover less.

MainPlank checks consent in this order:

1. Platform-wide revocation — absolute hard block. If there's a platform-wide "no" on record for this person and channel, no message goes out. Period. It doesn't matter what individual orgs have on record.
2. Org-specific revocation — blocks that org only. If someone has asked your specific organization to stop contacting them, messages from your org are blocked — but other orgs on the platform are unaffected.
3. Any valid grant — send is allowed. If there's no revocation at either level, and a valid grant exists with the right scope (transactional or marketing), the send goes through.

The key insight: A platform-wide revocation can't be overridden by an org-level grant. The hierarchy only flows one way — downward.

Consent records are write-once. Once an entry is created, it stays in the log forever. To change someone's consent status, you add a new entry (a grant or a revocation). The most recent entry is what counts.

This is intentional. If someone says "I never agreed to receive texts," you need to be able to show when the consent was recorded, who recorded it, and what source it came from. If entries could be deleted, that paper trail disappears.

Each entry in the log includes:

• The date and time the entry was created
• The channel (SMS or email)
• Whether it was a grant or revocation
• The source (who or what established it)
• The scope (transactional, marketing, or both)
• Which organization it applies to, or blank if platform-wide
• The staff member's account that recorded it (if a human did it)
• An optional note for context

1. Pull up their profile and look at the SMS consent history.
2. The log will show when the entry was created, who created it, and what source was used.
3. If an explicit_staff entry exists, a staff member recorded it — check the note field. If only an import entry exists, SMS consent shouldn't have been granted — investigate whether the send path was checking consent correctly.
4. Regardless of what the history shows: if the person wants to stop receiving texts, add a revocation entry immediately.

Add a platform-wide revocation for both SMS and email. This blocks all orgs from contacting them through MainPlank. Flag this clearly in the note field so future staff understand the context.

Add a new grant entry. The most recent entry always wins, so a new grant after a revocation restores consent.

Make sure the source is explicit_staff (if you're recording it for them) or explicit_self (if they did it in their account), and confirm the scope they're agreeing to.