How to add Microsoft Teams to TOTVS Protheus
Short answer
Build a Teams bot or Power Automate flow that receives Protheus events, posts adaptive cards for approval or review, and calls back into Protheus REST or ExecAuto when someone clicks. Authenticate users with Entra ID and map them to Protheus users so ERP permissions still decide what an approval is allowed to do.
Protheus users are typically spread across departments that already work in Microsoft 365: purchasing, finance, quality and planning. Approvals in the ERP wait because the approver is in Teams all day and in the Protheus screen once a week.
Teams is a good fit for the short, structured interactions in a mid-market ERP: approve this, acknowledge this alert, look this up. It is a poor fit for data entry, and the design should respect that boundary.
Because many Protheus installations are on-premises, the practical question is how a cloud-hosted Teams bot reaches an internal AppServer without opening the ERP to the internet.
What teams use it for
Purchase request and order approvals
Pending documents in the approval flow (alcadas) are pushed as adaptive cards with item summary, value and requester. Approve or reject posts back and the document moves on.
Stock and production alerts to channels
Stock below minimum on SB2 or an order stuck without material posts to the planning channel, with an action to open the item or raise a purchase request.
Quality non-conformance escalation
When an inspection result fails, notify the quality channel with lot, product and supplier, and let the owner acknowledge in Teams so the clock is visible.
Month-end finance reminders
Unposted invoices and unreconciled titles in payables (SE2) go to a finance channel with counts and owners rather than a spreadsheet emailed around.
Quick lookups through a bot
Ask the bot for the status of a purchase order or the stock of an item and get a card with live data, scoped to what that user may see.
TOTVS Protheus integration surface
- Protheus REST endpoints on the AppServer, standard or written in TL++, for reading approval queues and posting decisions.
- ExecAuto and the standard approval routines for purchase documents, so an approval from Teams follows the same rules as one from the Protheus screen.
- TOTVS Fluig workflow, where installed, which has its own REST API and can be the approval engine that Teams fronts.
- User exits and workflow classes in Protheus (the TWFProcess family, name varying by release) for emitting events when documents change state.
- Database views over SC1, SC7, SCR and SB2 for read-only alerts when REST endpoints do not exist yet.
How it works
- 1
Decide the engine: Power Automate, Azure Bot or both
Simple notifications and approvals can use Power Automate with an HTTP connector. Lookup and conversational use needs a bot built on the Bot Framework or Teams SDK.
- 2
Expose a narrow Protheus API
Publish read endpoints for pending approvals and status, and one write endpoint per decision type. Do not expose generic table access.
- 3
Bridge the network
Use an on-premises data gateway, a reverse proxy in a DMZ, or an outbound-only relay that polls the AppServer, so Teams never calls the ERP directly.
- 4
Map Entra ID users to Protheus users
Keep a mapping table of UPN to Protheus user code. The decision call runs as that user or with that user's approval level checked.
- 5
Design the adaptive cards
Show only what the approver needs, with a link to the Protheus or Fluig record. Cards update after the decision so nobody approves twice.
- 6
Audit and retry
Log every decision with Teams message id and Protheus document key, and make the write endpoint idempotent so a retry does not double approve.
Example flows
Purchase order approval card
Trigger: A purchase order lands in an approver's queue.
- Event hook writes a pending row; the relay picks it up.
- Bot sends an adaptive card to the approver in Teams.
- Approver selects Approve and optionally adds a comment.
- Bridge calls the decision endpoint, which runs the standard approval logic.
- Card updates to show the outcome and the next approver if any.
Result: Approval time drops from days of waiting to the same working day, with an audit trail.
Low stock alert with action
Trigger: A scheduled query finds items below minimum stock.
- Query reads SB2 for flagged items through a read-only view.
- A card lists the top items with open purchase coverage.
- Planner chooses Create purchase request for an item.
- Endpoint creates the request via ExecAuto with the planner as requester.
Result: Shortages are seen in the channel where planners already are, and the fix is one action away.
Keeping data on-prem
A Teams bot is inherently cloud-hosted, but nothing about the data has to be exposed. Keep the AppServer on the internal network and let an outbound-only relay or a gateway pull pending items and push decisions, so there is no inbound path to the ERP. Cards should carry summaries and a link, not full documents. For natural-language lookups, run the language model on-premises with open-weight models and let the bot call a tool layer that queries Protheus read-only. Messages themselves still live in Microsoft 365 under your tenant's retention and compliance settings, which you should review with your IT team before deciding what appears in a card.
Security checklist
- Authenticate with Entra ID and validate the token on your service; never rely on a display name in the message.
- Check approval authority inside Protheus on each decision, not only in the bot.
- Restrict channel membership for cards containing commercial values, and prefer one to one messages for sensitive approvals.
- Store secrets for the Protheus integration user in a vault and rotate them.
Ways to get it done
Power Automate flows with an HTTP connector
Effort: Days once the Protheus endpoints exist.
Quick wins for notifications and single-step approvals with modest volume.
Custom Teams bot built by your TL++ and .NET or Node team
Effort: A few weeks including the bridge and mapping.
Lookups, richer cards and multi-step approvals where you want full control.
Partner-delivered assistant such as Netray
Effort: Pilot on one approval and one lookup, then widen.
When you also want natural-language questions answered from Protheus data with the model kept private.
Pitfalls
- !Putting approval logic only in the bot so Protheus rules are bypassed.
- !Posting every alert to one busy channel until people mute it; route by owner and severity.
- !Not handling a document changed in Protheus after the card was sent, which leads to stale approvals.
- !Opening the AppServer port to Azure instead of using a relay or gateway.
Frequently asked questions
Can Teams approve TOTVS Protheus documents?
Yes, by having a bot or flow call a Protheus REST endpoint that runs the standard approval routine. The approver clicks in Teams, but the decision is validated in Protheus, so authority limits still apply.
Do I need Fluig to do this?
No. Fluig is a convenient approval engine if you already run it, but you can talk to Protheus REST directly. If Fluig owns your workflows, put Teams in front of its API instead.
How does the bot reach an on-premises Protheus?
Through an on-premises gateway, a DMZ reverse proxy, or a relay that only makes outbound calls. All three avoid exposing the AppServer to the public internet.
Is Power Automate enough?
For notifications and simple approvals, often yes. For free-form questions, multi-step approvals with comments, or per-user permission checks, a custom bot is easier to control.
Can the bot answer questions about stock or orders?
Yes, with a read-only tool layer over Protheus. Scope each query by the mapped Protheus user so people only see what they could see on screen. An on-prem model can interpret the question.
Want Microsoft Teams working on your TOTVS Protheus?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment