Approval Inbox

Collect internal approval requests, summarize them with AI, notify approvers, and record approve or reject decisions with an audit trail. The inbox holds one pending request at a time.

The user wants a Telegram-based internal approval queue for refunds, discounts, purchases, access requests, or other manager decisions.

• What kinds of requests should enter the approval inbox?
• Which contact tag should receive approval notifications?
• Should approval only log a decision, or should it call a real refund/discount/access API?
• Where should approval audit rows be stored?
• Send /start or /approvals to the bot to open the approvals inbox and decide on the latest pending request. The inbox holds one pending request at a time — a new webhook request replaces the previous one.
• Connect Google Sheets and map audit columns such as created_at, request_id, type, requester, amount, status, and summary. Decisions append a second row with the request id, decision, approver, and date.
• Replace webhook payload mappings with the real form, CRM, billing, or internal system fields.
• Add the actual post-approval action only after the team confirms which operations can be automated.
• Tag your reviewers with the tag you chose in setup (default "approver") on the Contacts page. The Notify approvers action messages everyone carrying that tag, so requests reach the right people without hardcoding chat IDs.

• Approval request arrives from webhook, internal form, or staff command
• Flow stores request id, type, requester, amount, reason, and raw payload
• AI_ACTION prepares a decision brief for approvers
• Flow marks approvalStatus as pending
• Contacts carrying the approver tag are notified
• Approver opens /approvals (or /start) and chooses approve or reject
• Both the pending request and the final decision are logged to Google Sheets

Good to know

• Route approval notifications to contacts carrying the approver tag (chosen in setup) instead of hardcoding Telegram user IDs or chat IDs.
• Single-inbox model: request details (approvalRequestId, approvalSummary, approvalStatus) are application-scope variables, so the bot tracks one latest pending request and a new webhook request replaces the previous pending one. For parallel approval queues, store requests in an external system keyed by request id.
• Keep the first version decision-only. Add payment/refund/access API actions after the approval policy and credentials are confirmed.
• Use Google Sheets insert-row as a simple audit log: the intake flow logs the pending request and the decision flow appends the final decision row. Replace it with a CRM, Jira, helpdesk, or internal API only after the destination is known.
• Approval decisions should be explicit button clicks or typed confirmations, not inferred from ambiguous free text.

Keep in mind

• Do not automatically refund, grant access, or change billing in the first version unless the user explicitly provides the approved API and policy.
• Do not infer approval from vague replies such as looks good.
• Do not send approval requests to customer audiences.
• Do not store sensitive payment details in variables or spreadsheet rows.