Procedures

Some things an app must never do in the browser: sign in to another company's service with a password, use a secret key, or keep a login token. A backend procedure is a small piece of code that runs on Operator's servers instead. The app asks it for a result and gets only that result back. Passwords, tokens and the other service's raw responses stay on the server.

Procedures are available in Pro apps. You describe what you need in plain words, and the App Builder writes, tests and connects the procedure.

When you need one

For work that must happen while nobody has the app open, use triggers.

Web Requests or Procedures?

Both keep credentials on the server. The difference is how much they can do, and what they cost.

Web Requests Procedures
What it does One call to one service Any secure logic: several calls, custom sign-in, checks with a secret
Sign-in it handles None, a stored key, or a standard company sign-in Any, including non-standard logins and signed requests
Remembers a login token No Yes, for up to 24 hours
Code None — just settings A small script the App Builder writes
Cost (after BETA) Included in the daily Cloud cost Daily cost plus 0.1 credit per run

Rule of thumb: start with a Web Request. Use a procedure only when a single standard call is not enough.

Examples:

The App Builder follows the same rule and tells you when it chooses a procedure.

Asking for a procedure

Our address provider DataMap signs in with a user name and password and returns
a token. Let the app search addresses as the user types, and keep the token so
we don't sign in on every search.
When the user presses "Check credit", ask our credit agency's service about this
customer and show only the rating and the limit.
Add a "Validate VAT number" button that checks the number with the EU service
and fills in the company name.

When the service needs credentials, the builder asks for them first. They are saved as Secrets, and you type them into a secure form. They never appear in the conversation or in the app.

What you see in Cloud → Procedures

Who may use a procedure

A procedure can be open to everyone who can run the app, or only to the people who design it. The second option suits admin tools. When a procedure reads ERP.net data, it does so as the person using the app, on the instance they are working in.

Cache

Procedures and triggers can remember small things for a limited time. This is usually the sign-in token of another service, so the app doesn't sign in again on every click. Each item expires on its own, after at most 24 hours.

Cloud → Cache lists what is currently remembered. For each item you see its name, whether it belongs to one instance or all of them, its size, and when it expires. The contents are never shown, because they are often tokens. Press Clear on an item, or Clear all, to make the app sign in fresh on its next call. This is useful after you change a password.

Good to know