Workspace Automation Controls
The end-user guide to schedule setup, webhook triggers, Telegram and WhatsApp controls, and what each workspace automation setting changes.
When automations become available
Workspace automations are not meant to be configured in a vacuum. In the current product flow, they become meaningful once a workspace-backed post exists and the workspace is activated enough to participate in real user flows.
For many users, the first visible automation controls appear around the featured profile workspace.
The app treats automation setup as part of the overall workspace configuration rather than as a separate product.
Schedule and place activation
A profile workspace becomes more automation-ready after you save a place and a future date/time.
Those two fields do more than fill in profile details.
| Setting | What it means to an end user |
|---|---|
| Place | The real-world or mapped location tied to the workspace context |
| Date/time | The future point that activates the scheduled part of the workspace flow |
In practice, this setup helps the app understand when the workspace should behave like an active scheduled experience instead of only a generic draft.
If the page says the workspace still needs place + date/time, finish that step before expecting Telegram, WhatsApp, or trigger-driven automation controls to behave as ready.
Telegram bot setup
Telegram setup lets a workspace participate in Telegram-driven automation flows.
The visible settings map to user-facing choices:
| Setting | Plain-English meaning |
|---|---|
| Telegram bot token | The credential that lets your workspace act through your Telegram bot |
| Mode | Whether Telegram communication is fetched by polling or delivered through webhooks |
| Enabled | Whether Telegram automation is active for this workspace |
| Auto-reply enabled | Whether the workspace should automatically answer through Telegram |
| Webhook secret | The secret Telegram uses when webhook mode is enabled |
| Webhook path / URL | Optional overrides for where Telegram should deliver webhook events |
For most users, polling is the simpler default. Webhook mode is better when you need lower-latency delivery and a more explicit inbound endpoint.
The practical rule is simple: do not enable Telegram until the token is valid and the workspace is otherwise ready.
WhatsApp setup
WhatsApp setup follows a different interaction model because it is based on linking a WhatsApp session.
The visible controls explain what the workspace is allowed to process:
| Setting | Plain-English meaning |
|---|---|
| Enabled | Turns the WhatsApp connection on or off for the workspace |
| Auto-reply enabled | Lets the workspace answer automatically instead of only receiving messages |
| Process chats | Chooses whether only direct messages or both direct messages and groups are processed |
| Process senders | Restricts whether only your own messages, your self-chat, or any sender can trigger behavior |
| Generate QR | Starts or refreshes the linking flow for WhatsApp Web style connection |
| Refresh status | Re-checks whether the linked session is active |
| Logout WhatsApp | Disconnects the current linked session |
You may also see a connection status and QR expiry indicator. Those are operational cues for whether the current link is still usable.
From an end-user perspective, the sender and chat scope controls are the most important safeguards. They determine how broad or narrow the automation's listening behavior is.
Signed webhooks and purchase-driven runs
Not every automation starts from Telegram or WhatsApp.
GetPaidX also supports trigger-driven automation behavior such as:
- signed webhook events,
- purchase-succeeded flows,
- scheduled runs.
The important end-user meaning is that a workspace can react to business events instead of waiting for someone to manually open it.
Use signed webhooks when an outside tool or service should safely trigger a workspace flow. Use purchase-driven runs when the act of buying should kick off fulfillment or follow-up behavior. Use scheduled runs when the workspace should do work at planned times.
The safest way to think about automation controls is:
- activation controls decide whether the workspace is ready,
- channel controls decide where messages come from,
- trigger controls decide what kinds of events can start automation work.
That mental model is enough for most end users and avoids dragging low-level implementation details into the manual.
Related docs
See it in action
Previous
Workspace Runtime, Preview, and Publishing
How runtime defaults, live preview startup, static preview files, and published artifact site settings map to the Config tab.
Next
Workspace Billing, Access, and Collaboration
What author pays vs collaborator pays means, how purchase requirements work, and how edit collaborators are granted or restricted.