Precise beats absolute.
Our extensions run inside the SAP Field Service and Asset Management Shell (formerly SAP FSM), against your tenant's own access token. Your records never touch our servers — and rather than leave it at that, this page lists exactly what does, what happens when something breaks, and what an AI call carries if you switch one on.
A page that over-claims by one word fails at the security review it was written to pass. Everything below is meant to survive that reading.
Three paths, and two of them are entirely yours
Browser ↔ your FSA cluster
The extension calls the FSA APIs directly from the browser, with the access token the Shell already issued it. Service calls, activities, business partners and your user-defined objects travel this way. We do not proxy it and we do not see it.
Browser ↔ your engine ↔ your S/4
Anything involving S/4 goes to a connectivity engine you deploy into your own BTP subaccount, holding your credentials, reaching your system over your network path. Both ends of that path are infrastructure you own.
Browser ↔ Altiwerk
One conversation: is this licence valid, and what does it cover. It is cached for an hour. The full contents are in the table below — there is nothing else.
Two independent connections. Record data never crosses the bottom path. Live S/4 reads and writes take a third path, from the same browser to a connectivity engine on your own BTP — it does not pass through here either.
The S/4 path is drawn in full on how it works.
The whole list, not a summary of it
If a thing is not in this table, it does not leave your landscape.
| Data | When | Why | Contains |
|---|---|---|---|
| Account id, licence id, entitlements | On app load, then cached for an hour | Validating that the licence is real, current, and issued for this tenant | No record data |
| An opaque user id | First use within a seat window, only on seat-capped licences | Counting how many distinct people are using the licence | No name, no email address, no role |
| Install id, app version, last-seen | Periodically, while the app is open | So we can tell you which of your installs is running an old build | No record data |
| AI usage counters | Only while AI is switched on, and only when a model is actually called | Cost visibility and billing | Call count, token count, model name, day. Never the prompt, never the answer |
| Standard HTTP metadata | On the requests above | It is how HTTP works — user agent, IP address | No record data |
What never reaches us
- ✕Service calls, activities, business partners, equipment
- ✕The records of your user-defined objects
- ✕S/4 data in either direction — that path runs browser → your engine → your S/4
- ✕SAP ERP documents
- ✕User names, email addresses or roles
- ✕AI prompts and the answers to them
- ✕Any field-level tenant data, of any kind
S/4 sees the technician, not a service account
The engine propagates the caller's own identity to S/4 rather than replacing it with one shared technical user. What a person can read and change through our screens is exactly what S/4 already says they can — the authorisation model you have already built is the authorisation model here.
The alternative, which is what most connectors do, has two consequences worth naming. Every user effectively inherits the union of everyone's rights, because the service account needs enough access for the broadest case. And an audit trail in S/4 records the service account, not the person — so “who changed this?” stops having an answer.
Opt-in per entity, and never silent
- ·The engine can only write to entities that have been explicitly allowed. It is not a permission it can grant itself, and it is not a default.
- ·Every write carries a concurrency check. If somebody changed the record first, the user is shown the conflict and decides — nothing is quietly overwritten.
- ·A rejected batch is re-planned into the smallest units that can succeed, so one bad field does not silently cost the other forty rows.
How the awkward scenarios actually play out
The key only validates when paired with the account id it was issued for. Anyone pasting it into another tenant is rejected server-side — they never see your data and never get past the blocking screen. Tell us and we revoke it; the leaked copy stops working within the hour as caches lapse.
The licence carries an absolute expiry. After it, validation returns expired and the app shows a renewal message. The screens you built stay in your FSA tenant as your own records — they were never stored with us, so there is nothing for us to hold hostage.
Nothing happens. Expiry is evaluated server-side against synchronised server time; the local clock is not consulted.
We rotate the keypair, deploy the new public key and reissue every active licence. Old keys stop verifying immediately. The blast radius is small by construction: those keys sign licence tokens and nothing else — no operational data is ever encrypted with them.
It will not start. The verifying key is compiled into the engine binary rather than read from its environment, so a self-signed licence fails at boot. And a running engine checks the calling tenant against the accounts its licence covers, on every request.
Each install reports its version periodically, so we can tell you which one is behind — the same heartbeat listed in the table above. It carries no record data.
Three components, three different answers
“We fail open” and “we fail closed” are both wrong as a blanket statement, so here is each case on its own. This is a procurement question worth pre-answering.
The last successful verdict is reused for up to 24 hours, so a short outage is invisible. After 24 hours without contact the app closes with a clear message naming the reason — not a silent loss of features.
A bad afternoon for us must not be a bad afternoon for a field team. Indefinite grace, though, would mean a licence that never really expires.
The user is let in. A seat check that cannot run never blocks somebody who is trying to work.
Seats exist to price fairly, not to police. Failing closed here would turn a database blip into a technician standing in front of a customer with no app.
It keeps serving until its current lease expires, then stops. The licence is verified offline against a key compiled into the engine, so this needs no connectivity at all in the normal case.
Your engine runs in your landscape and must survive our outage — but a contract that has genuinely ended has to be enforceable without asking you to redeploy anything.
Enforced. Expiry is checked against server time, so changing a device clock does nothing, and a revoked licence stops working as caches lapse — within the hour.
This is the one place where failing open would make the whole licence meaningless.
Off unless you turn it on — and then, exactly this
AI is optional. Nothing is sent anywhere unless a tool is switched on at all three levels and a key is configured. When it is on, this is what a call carries.
| What is sent | What is not |
|---|---|
| Field and entity names, and their labels, when a field or a mapping is being explained or suggested | The values in those fields |
| The text of an SAP error, after identifiers are stripped from it | The record the error was about |
| The sentence you type into the natural-language bar, when that tool is switched on | The rows it filters, before or after |
Many answers need no model call at all — error explanations are answered from a curated knowledge base first, which works with AI switched off entirely. The three-layer switchboard, the model allowlist and the spend counters are on the AI page.
Where the licence service runs
The part of this system that we operate is small on purpose: a licence-validation service and the store behind it. It never holds record data, which is what makes the rest of this page possible to state so plainly.
We provide the current list of sub-processors and their hosting regions in writing on request, and we will put it in front of your security team before you sign anything. If a specific region is a requirement on your side, raise it early — it is a better conversation before a contract than after one.
What your own landscape holds
- ·Every screen and configuration, as records in your FSA tenant.
- ·The connectivity engine, in your own BTP subaccount, with your S/4 credentials.
- ·All S/4 traffic, on your network path — it never transits ours.
If you stop renewing, that is all still yours. There is no export to request.
Need a security review before purchase?
We'll walk your IT and security team through the architecture and answer questions in writing, including the ones this page did not anticipate. No NDA needed for the basics.