What actually happens when a workflow runs

TallyPrime runs on a desktop and has no public address. That single fact shapes everything about how Balancely is built, so it is worth walking through what happens in the moment a workflow fires.

The four pieces

• An application: your tool's identity, with a key and a list of what it may do.
• A connection: one TallyPrime company on one paired computer.
• The connector: a small program on that computer, holding a line open to us.
• The service: where requests arrive, are checked, and are turned into what TallyPrime understands.

How a request reaches a desktop

The connector makes an outbound connection to us and keeps it open - like a browser tab, or a chat app waiting for messages. Requests travel down that line. There is no port forwarding, no static IP, no firewall rule and no VPN, because nothing ever connects inward to your computer.

The two seconds

1. Your platform posts to the API with the application's key.
2. We check the key, the permission, and that the connection it names is online.
3. The request is shaped into TallyPrime's own format and sent down the open line.
4. The connector hands it to TallyPrime and waits for the answer.
5. We read the record back, and build your response from what was actually saved.

Why we read it back

TallyPrime can say "success" while having saved nothing - a locked company, a ledger that does not exist, a date outside the financial year. So after every write we read the voucher back before answering. If it is not there, you are told, with the reason in plain words.

Why a retry never posts twice

Platforms re-send a step after a network hiccup. Every write carries a fingerprint, so a repeat updates the same record instead of creating a second one. You can send your own idempotency key if your workflow already has a natural one, such as an order number.