Last updated: 6 September 2026
This page describes how the Item Approval Workflow app for monday.com is hosted, what it can and cannot reach, how it decides who may do what, and how to tell us about a vulnerability. It is written for the person in your organisation who has to sign off on installing it.
The app runs entirely on monday code, monday.com's own hosting for marketplace apps, in the European Union region. Its data is one JSON record per board, plus a small index per account, kept in the storage that platform gives the app.
We operate no infrastructure. There is no server of ours, no database of ours, no backup of ours and no administration console. There is nothing of ours for an attacker to break into, and no credential of ours that would unlock your data.
The app calls no external service: no analytics, no error reporting, no AI service, no third-party API. The only network it speaks to is monday.com's own. It sets no cookies, registers no service worker and stores nothing in the user's browser.
At installation your account authorises the app once, on monday.com's own consent screen. It asks for two permissions and nothing else:
It does not ask for permission to read your updates, your files, your assets or your users' profiles, so it could not read them if a future version tried. The key monday.com issues is held per account in the platform's own encrypted vault, is used only on the server, is never sent to the browser or written to a log, and is deleted when the app is uninstalled.
Why the app needs to read the board at all, since this is the extra consent screen you are being asked for. The whole product is the sentence "the approval belongs to a version of the item". If the content of the item were reported by the browser instead of read from monday.com, anyone with the developer tools open could send the old content and keep a green stamp on an item they had just changed — which is exactly the failure this app exists to fix. Item content is read on the server, from monday.com, or the approval means nothing.
All traffic is HTTPS. Data at rest is encrypted by monday.com as part of the platform. The secrets the app needs — the keys monday.com uses to sign what it sends, and the per-account authorisation key — are held in the platform's own secrets store and vault, mounted into the running app, and never written into the source code or into any log.
The app has no login of its own and no password to steal. Every call from the screen carries a token issued and signed by monday.com. The server verifies that signature before doing anything at all, and takes from that token only: who you are, which account you belong to, and whether you administer it. Nothing the browser asserts about identity is trusted.
Every authorisation check runs on the server, on every call — never by hiding a button:
DELETE must be typed, and the server checks
that word again.The rules are the same whether you click or talk. The app publishes six actions for the assistant that already lives in your monday.com account. They do not carry a second copy of the rules — they call the same server code the buttons call. Somebody who may not approve an item cannot approve it by asking, an item that changed after it was sent is refused rather than rubber-stamped by voice, and who signs off is never chosen from a spoken name.
Every record is addressed by the account ID taken from the signed token, never from the body of a request. The automated test suite contains cases that prove one account cannot read, decide on, or erase another's data.
monday.com notifies the app when an account installs it, uninstalls it, or changes its subscription. That endpoint sits behind an address that ends in a secret held in the platform's secrets store and registered only in monday.com's developer console; no screen in the app ever calls it, so no user of the app ever sees it. An unknown key is answered as if the address did not exist.
The reason is specific rather than decorative. Those notices are signed with the same key as an ordinary user's token and contain the same fields, so there is no property of the message itself that distinguishes a genuine platform notice from one forged by any logged-in user. Since the notice is what triggers erasure, and the account it names comes from its own body, without that secret address anyone could have asked the app to erase a company. The signature is still checked, and the account named in the token must match the one in the body.
To tell whether an item changed after it was approved, the app keeps a snapshot of the columns it watches — the item name, and for each watched non-empty column a preview of its value cut at 512 characters plus a short summary used for comparison. That is board content, and the Privacy Policy says so in those words. Columns the platform writes or calculates by itself never count and are never stored, and a board owner can narrow the watched list to specific columns on the Setup tab.
Email help@saoirsesoftware.com with the word SECURITY in the subject. Please include what you found, how to reproduce it and what you think the impact is.
If a security incident affects data processed by the app, we will contact affected customers without undue delay, and within 72 hours of becoming aware, describing what is known, the likely impact and what is being done. Section 9 of the DPA sets this out, including how to give us a specific mailbox for such notices.
Everything the app holds for your account is erased automatically when you uninstall, and can be erased at any time by an account administrator from the Setup tab — either all of it, or one person's identity. All routes delete rather than mark as deleted, and we keep no copy to restore from. Erasing is never blocked by billing.
Item Approval Workflow is supplied by Kauê Natan Gonçalves Bidim, trading as Saoirse Software, in Ireland. Security reports and questions go to help@saoirsesoftware.com.