The app now lives at its own address. Where the web app, the mobile app and the install links used to be published on the hosting provider's own domain, they are now published on ours: the app at app.altiwerk.com and the mobile version at pwa.altiwerk.com. The old addresses have not been switched off and do not need to be — they forward to the new ones, permanently and without losing anything on the way, so anything you have already installed keeps working untouched and no link anyone has been given goes dead. What changes is what gets handed out from here: a newly copied install link, and the address a newly installed extension is registered under, now name the new home. If your organisation restricts which addresses its browsers may reach, both the new addresses and the old ones should be on that list for the time being — extensions installed before today still start from the old address before being forwarded, and only stop needing it once they are reinstalled.
227 releases, written for you.
Every release we have shipped for SAP Field Service and Asset Management (formerly SAP FSM) since 2026, newest first. These are the notes the app itself ships — the same words your users read inside it, not a rewrite for this page.
Currently shipping v1.5.203. Inside the FSA Shell you always load the current version — there is no upgrade step to schedule.
227 releases, newest first.
New objects the app creates in your company are now named ALTI_ instead of ESV_, and new records are stamped with the company's name. This is a rename of the app's own namespace following the company becoming Altiwerk, and it is being done now, before the first customer, because SAP FSA offers no way to rename or cleanly delete a user-defined object once it exists — the moment of naming is the only cheap moment. Nothing you already have stops working: every record signed by an earlier version is still recognised and read exactly as before, so screens, settings, saved S/4 templates, rename batches and report layouts all continue to open. What changes is only what gets created from here: a new screen's store, a new field, a new user-defined object. On a company that was already in use, the objects created under the old name stay where they are — FSA cannot remove them — and the app no longer reads them, so screens built before this release should be exported with Backup and imported again afterwards, which rebuilds them under the new names. Backups carry the design of a screen rather than its records, which was the deliberate trade: the screens are what took the work.
S/4 records whose key includes a date can be fetched again. Some S/4 records aren't identified by a number alone — equipment, for one, is identified by its number together with a validity date — and S/4 hands that date back as a full timestamp, '2026-06-16T00:00:00.000Z', where a date is all that was ever meant. Handed straight back to S/4 as part of a key, that timestamp isn't something S/4 will accept: it answered 'Malformed URI literal syntax' and the record didn't come. On most systems this never showed, because the records in front of you carried the far-future default date the app fills in for you and never had to repeat S/4's own wording back to it; on a system whose equipment carry real validity dates it showed at once. The app now speaks about dates the way S/4 expects to hear them, wherever a date takes part in identifying a record — fetching one, filtering a list by one, or writing one back. In S/4 Live the same date is also written the way you would write it: the one-click examples under the key fields now read '2026-06-16' rather than the timestamp, and clicking one fills the field with exactly that and fetches the record. If a key genuinely carries a time of day, that is kept as it is — the time is part of which record you asked for.
Licenses now cover a number of people, and the app says so plainly when they run out. A license has always been for a company; it now also carries how many of that company's FSA users may use the app, and the count is kept centrally rather than on anybody's machine. You are counted as one person however you work — your laptop, your phone, a second browser and a new sign-in tomorrow are all the same seat, and the count is of people who have actually opened the app recently rather than everyone who ever has, so someone who leaves, or is away for a season, quietly stops taking up room without anyone having to tidy up after them. Nothing changes for you while there is room. If your company's seats are all taken and you are someone the app hasn't seen before, you now get a screen of its own that says exactly that — 'No seat available', how many seats are in use, and that your administrator can free one or add more — rather than the old 'License problem' card, which pointed at a license that is in fact perfectly valid and sent people to the vendor for something their own administrator fixes in a moment. There is a Try again button for the moment they do. Anyone already using the app keeps working no matter what: reaching the limit, or having it lowered, never turns away someone who is already counted, so a busy day can't lock out the people in the middle of it. And if our own licensing service is unreachable when you open the app, you are let in rather than kept out — an outage of ours is not a reason to stop a field team working.
UDO screens can now scope themselves to the record whose tab they are open in. The screen designer has offered an "Auto-fill from host tab" setting on UDO screen fields for a while — you could tick it, choose which record type to read from and which of its values to use, and save it without complaint — but the viewer never did anything with it: the screen carried on showing every record regardless of where it was opened. It now works, and behaves the way the same setting already does on SAP document screens. Install a UDO screen on, say, an Equipment page or a Service Call tab, and when it opens it reads the chosen value off the record you are looking at and filters itself to it, so the screen shows that record's rows and not the whole table. Move to another record and it re-scopes itself; there is nothing to type and nothing to remember. How much freedom you keep is up to whoever set the field up. Left as it comes, the filter is shown but fixed — you can see exactly what the screen is scoped to and why, marked with a small link icon, but you can't accidentally widen it. It can instead be hidden entirely, so the screen simply shows the right rows with no filter on display, or left fully editable, in which case it behaves like a filter you typed yourself and clears like one. In the first two cases Clear leaves the scope alone: clearing a filter should drop the filters you added, not quietly hand you somebody else's records. The same applies to "Ask this screen": it can still filter and sort within the scope, but it is no longer offered the locked field, so no phrasing of a question can talk the screen out of the record it belongs to. If the record you have open has no value for the chosen field — it was never filled in, or the link hasn't been made yet — the screen says so plainly ("Nothing linked here yet", naming the field it needed) instead of falling back to showing everything, which is the one outcome that would be genuinely wrong in someone else's record tab. In the workspace, where there is no host record, nothing changes at all.
SAP document screens now let you drag your fields into the order you want, the same way UDO screens already did. Until now the order of the filters across the top and the columns across the table was whatever the screen's designer had set, and nothing in the viewer could change it — if the field you filter on every day sat fourth, it sat fourth. Every field now carries a small ⋮⋮ grip: take hold of it and drop it where you want the field to be. On the document list the grip is in four places and they all share one order, so it doesn't matter which you use — the filter bar, the column headers of the table, the Adapt Filters list and the View Settings list. Move a field in any one of them and it moves in all four at once, which means you can reorder from the list dialog with everything laid out in front of you and then watch the table follow, or just drag a column header while you're reading the table. It carries on inside an open document too: the items table has the same grips on its column headers, and so does the sub-items table that opens underneath a row. Each item tab keeps its own arrangement, and the items table and its sub-items table are arranged separately, so putting Quantity first among the items doesn't disturb the sub-item columns. Dragging a header never sorts it by accident, and in edit mode dragging a column header never gets mistaken for dragging a row — the grip is its own handle, and clicking the header itself still sorts as before. Your order is remembered per screen on this browser, so it survives closing the tab and comes back the next time you open that screen, and each screen keeps its own arrangement rather than one order being forced on all of them. If you want the designer's original order back, Reset in either Adapt Filters or View Settings restores the list, and a '↔ Reset columns' button appears above the items table once you've rearranged it. The grips step aside while you're searching within either dialog, since a shuffled search result isn't something you can meaningfully drag. Two things stay as the designer laid them out: the card display mode and the form you fill in for a new item, neither of which is a column grid, and the CSV export, whose column order files depend on.
Deleting a batch of records now asks once, then shows you the delete happening. Selecting twenty documents and pressing Delete used to put a browser pop-up in front of you for every single one — twenty questions to answer for one decision you had already made — and once you were through them the table simply froze, with nothing to say whether anything was being deleted or how far along it was. You now get one dialog, in the app's own styling, naming exactly what is about to go: the count, the fact that items and sub-items go with their document, and the records themselves listed so you can see you picked the right ones. Confirm it and that dialog turns into a progress panel — a bar, a running clock, the record being deleted right now, '7 of 20 documents · 35%' and an estimate of the time left. There is a Stop button: it finishes the record in flight and stops there, so nothing is ever cut off half-deleted, and whatever survived stays selected so you can pick up where you left off. A record FSA refuses never stops the run — it is set aside and the rest carry on — so one locked record can no longer strand the other ninety-nine. At the end you get the tally: how many were deleted, how many failed, how many were never attempted, and how long it took, with every failure named and carrying the reason FSA gave instead of vanishing into a red toast. That list has its own scrollbar and its own fixed height, so the window stays exactly the same size whether three records failed or three thousand, and the counts stay in view while you scroll through them; above the list the reasons are grouped and counted ('254× locked by another user'), because a very long failure list is usually a handful of causes repeated, and ⧉ Copy puts the complete list on your clipboard for a spreadsheet or a ticket. From there you can Close, or press 'Retry N failed' to run the delete again over exactly those records — all of them, whether or not the list showed them, and with no second confirmation since you already gave one — and the summary keeps count across attempts, so it can still tell you how much of your original selection is gone. This is the same for both the SAP document screens and the UDO screens, and single-record deletes ask in the same dialog rather than the browser's. Batch delete is also quicker than it was: it used to re-read the whole company's items and sub-items once per document and rewrite the screen's history after each one, and now does both once for the batch, with a single list refresh at the end instead of one per document.
Creating an extension now shows you only the link you actually asked for, and stops asking questions that don't apply. Publishing to Mobile only used to end on a screen offering both a web install URL and a mobile one — two links for a single-surface extension, with no way to tell which of them FSA would accept. You now get exactly one link per surface you published to: mobile only gives the Web Container URL with the Web Container instructions, web only gives the FSA install URL, and only 'Both' shows two, each labelled for the surface it belongs to. The mobile instructions also name the right place to go — FSA Admin, your company, Web Containers. Choosing Mobile hides the whole 'Available on' picker, since outlets are a web-extension idea: a mobile install is just a URL, with no Service Call tab or Equipment page to pin it to; a one-line note says so, and the eighteen checkboxes come back the moment you switch to Web or Both, with your ticks intact. Those eighteen are no longer all on screen at once either — the dialog opens showing the three placements nearly everyone uses (home screen, Service Call, Equipment) and folds the sidebars, Partner Portal outlets and the rarer master-data pages behind a 'Show 14 more places' line you can open and close. Anything you've already ticked stays visible when folded, so nothing gets published to a place you can't see. Finally, the 'Technical details' fold at the end is gone: it showed hosting internals that answered no question anyone installing an extension actually has, and read as though your screen and its data were being kept somewhere other than your own FSA company. They aren't — but the panel invited the question, so it no longer appears.
The UDO designer now checks a new name against the UDOs your company already has, before it creates anything. Creating a UDO with a name that is already taken — anywhere in the company, not just on the screen you're looking at — is blocked, and the box tells you which of the two it clashes with. Naming a field the same as an existing UDO is allowed but now warns you first: that combination works perfectly everywhere in this app, but SAP's own FSA Admin will not list the field under the other UDOs that link it, so a field called ESV_PLANT can look like it has gone missing when you go looking in FSA. The warning explains that, suggests a name that avoids it, and lets you carry on if you meant it — naming a field after the object it points at is a perfectly reasonable thing to want. Both checks matter because FSA has no rename and no clean delete for either a UDO or a field, so the moment you type the name is the only cheap moment to change your mind.
Restoring a backup into a new company can now create the UDOs your screens read. Until now a UDO screen imported into a company that didn't have its UDO looked like it had worked, and was then broken — opening it in the designer only gave you a red 'UdoMeta "…" not found in FSA' and left you to build the UDO by hand before the screen would show anything. A backup now carries the definition of every UDO its screens read — the fields, their types, whether they're required, and the options behind any dropdown — so the restore can build them for you. On the review step before anything is written you get a list of the UDOs this company is missing, each already ticked, showing how many fields it will get and which screens want it; untick any you'd rather map by hand. They're created first, before the screens, and appear as their own row in the restore progress panel with the same running count as everything else. Two things worth knowing. Creating a UDO writes company-level metadata rather than just that screen's own store: it stays after the screen is deleted and FSA has no clean way to remove it, which is why every one of them is a tick you can undo. And a backup exported before this release carries no definitions, so those UDOs can't be created — the review step says so per UDO and tells you to re-export the backup from the company it came from, which is all it takes. Separately, the UDO screen designer no longer answers a missing UDO with a red error. It explains in place that this company has no such UDO, that the screen was most likely restored from elsewhere, and offers to create it — empty, ready for + Add Field — while pointing you at the re-export route if you want its fields as well.
Restoring a screen backup now shows you what it is doing. Pressing Restore used to grey the button to 'Restoring…' and leave the preflight table on screen, so a restore into a fresh company — which can legitimately run for several minutes — was indistinguishable from a hang. It now opens a progress panel of its own, the same one you know from Push & Save in SAP document screens: a running clock, a bar for the whole restore, and a line naming the exact step in flight, down to "Items · adding field 'Required Quantity' (14 of 31)". Underneath, every screen in the backup has its own row that starts grey, turns to an hourglass with its own small bar while it is being written, and settles to a green tick with the seconds it took — or a red cross carrying FSA's own words about what went wrong, while the remaining screens carry on. Once enough of the run is behind it the panel also estimates the time left. The reason a restore is slow is now visible rather than mysterious: every field of a screen has to become its own FSA field definition, created one request at a time, so a document screen with 40 fields is over 40 sequential requests — the panel counts them off. The dialog also stops closing when you click outside it mid-restore, since the writes carry on regardless, and the summary at the end now says how long the whole thing took and how long each screen took.
The workspace list in the sidebar folds away in one click, giving the screen list the height back. Under the last workspace there's now a small ⌃ — click it and Viewer, Admin, S/4 Live and the rest shrink to a two-row strip of icons; click the ⌄ again and the names come back. Folded, the sidebar shows roughly three times as many screens before you have to scroll. Nothing becomes unreachable: the icons stay in place and stay clickable, and hovering one shows its name, so you can still switch workspace while folded — the one you're in stays highlighted. The app remembers your choice per browser, so if you always work in the screen list it stays folded until you unfold it. This is separate from the ☰ button in the header, which hides the whole sidebar including the screen list.
The admin screen list now has the same quick filter as the viewer's sidebar. Type a few letters into the box above 'Group by' and the list narrows to the screens whose name contains them — the grouping stays exactly as you left it, whether by type or by category, and empty groups drop out of the way. Press Escape or click the × to clear it and get the full list back. Nothing else changes: the filter only affects what the list shows, so the count on the collapsed list, the screen pickers when publishing an extension, and everything on the right-hand side are untouched. With a few dozen screens it saves scrolling through collapsed categories to reach the one you meant to edit.
Report screens get a download menu, including the whole report as one Excel file. The report toolbar now has a CSV button listing every table — each showing how many rows it will export, greyed out when a table hasn't run yet — plus 'All tables (.xlsx)', which downloads the entire report as a single Excel workbook with one sheet per table, named after the screen (a screen called Standard FSM Reports gives you Standard_FSM_Reports.xlsx). A workbook rather than several files: inside FSA every separate download needs its own handover window, and tables can't be merged into one CSV because each has its own columns. In the workbook a cell carries its own type, so the data arrives the way it looks on screen — a plant like 0001 stays 0001 and a material like 000000000000000103 stays whole instead of becoming 1 or 1.03E+17, quantities and prices arrive as real numbers you can sum and sort, and a value beginning with = or + is text and can never be run as a formula. There is no separator or encoding to get wrong, so files open the same on a German or English Excel. Single tables still download as CSV — those are now written like the master CSVs elsewhere in the app, with the same protection for leading zeros, formula-looking values and text containing commas, quotes or line breaks. The ⬇ inside each table is unchanged and still exports exactly what you see, filters and sorting included; the menu does the same for any table without scrolling to it. Admins can hide the new button per screen under 🖥 Screen Settings ▸ Toolbar.
Downloads inside FSA actually arrive now. Since the last release the file reached your browser's download list with the right name and then failed there — Brave showed "Check internet connection" with a Try again button, which made it look like your network. It wasn't. Because an extension runs in a frame belonging to another site, the browser keeps its temporary file storage separate from the little window the app has to open to hand a download over — so the window was being sent to fetch a file it was not allowed to see, and the download died at the last step. The app now prepares the file inside that window instead of handing it a reference it can't use. A second, quieter problem is fixed with it: the window used to close itself about a second after starting the download, which cancelled anything still waiting — most visibly if your browser asks where to save each file. It now stays open long enough and closes itself. This applies everywhere a file leaves the app: every CSV button on document, UDO, report and custom screens, the master CSV downloads, the failed-rows file from a bulk upload, screen backups, Stock Checker and Checklist Studio exports, and the Attachment Renamer's download and PDF preview. Also: on document screens whose records come from S/4, the CSV upload switch in Screen Settings is now shown as unavailable with the reason, instead of letting it be switched on and then never appearing in the screen — those documents are a mirror of S/4 and must be created with "+ New in S/4"; their master downloads are unaffected.
Bulk CSV upload now also works on SAP-document screens — same flow as UDO screens, at the document-header level. The CSV button on the document list is now a menu: 'Current view' is the export you already had, and the two new master files ('All documents' / 'Empty template') carry every header field plus _id and Doc #. Fill rows in Excel and upload the file back: rows with an empty _id become new documents — each automatically receives the next document number, exactly as if created one by one — and rows whose _id matches an existing document update just the header fields you changed. Doc # itself is never taken from the file, so numbering can't collide. The same review-before-write, progress bar, failed-rows download and '↺ Undo this import' apply; new documents start without items (add them in the document, where the existing per-item CSV import now also understands semicolon-separated Excel files, quoted multi-line values and leading-zero guards). Uploading writes to FSA only — nothing is pushed to S/4. Off by default: turn it on per screen under 🖥 Screen Settings ▸ Bulk data; screens whose documents are a synced S/4 projection never offer the upload. Also fixed while proving this live: re-uploading an untouched export row no longer gets rejected when an older record left a now-required field empty — an empty cell over an already-empty field clears nothing and is allowed through.
Bulk upload for UDO screens: fill a CSV in Excel and create or update many records at once. The CSV button is now a small menu. 'Current view' is the export you already had; new are two master files — 'All records' and 'Empty template' — which carry every field of the screen (hidden ones too) plus an _id column holding each record's identity. Fill rows and upload the file back with '⬆ Upload filled master…': rows with an empty _id become new records, rows whose _id matches an existing record update just the fields you changed, and rows identical to what's stored are left alone — so re-uploading a full export you edited updates the three rows you touched instead of duplicating all of them. Nothing is written before you see the check results: one review shows how many rows will be created, updated, left unchanged or skipped, and names each problem row — a missing required field, an unknown _id, a duplicate, a date the file made ambiguous — then one click imports the valid rows. A progress bar runs the writes; the summary offers the failed rows as a CSV to fix and re-upload, and '↺ Undo this import' puts everything back — created rows deleted, updated rows restored to their previous values. The files are Excel-proof: semicolon-separated files from German/EU Excel are understood, umlauts survive, and values with leading zeros (plant 0001) are guarded so Excel can't strip them. Uploading writes to FSA only — nothing is pushed to S/4; run ⟳ Sync afterwards to fill S/4-linked and copied fields. The upload is off by default: an admin turns it on per screen under 🖥 Screen Settings ▸ Bulk data, and it's a desktop feature (hidden on phones and tablets). The downloads are always available and need no setting.
CSV export and file downloads work again inside FSA. On SAP-document, report, UDO and custom screens, pressing CSV said "Exported 42 documents to CSV" and no file ever arrived — and the ⬇ on an attached file did nothing at all. The cause was the FSA window itself: extensions run in a restricted frame that quietly discards a download the page starts on its own, so the app reported a success that never happened. Downloads on those screens now go out through a small window the app opens for the moment it takes to hand the file over, the way the Attachment Renamer and the other studios already did. Nothing changes outside FSA. If your browser blocks pop-ups the download can't be handed over, and instead of a false success you now get a message asking you to allow pop-ups for this app.
You can now back up your screens to a file, and restore them — here or in another company. In the admin screen list, ⇅ Backup opens a list of your screens, all ticked: leave it as it is to back up everything, or untick what you don't want and back up just those. There's a filter box when the list gets long, and the ⬇ on any screen row exports that one screen directly. Restoring is the same dialog: drop the file back in and you get a review BEFORE anything is written — what each screen will do, which UDOs the file expects that this company doesn't have, and which S/4 services it reads. Each screen gets its own choice: import it as a new copy, overwrite the existing screen of that name, or skip it. Overwriting restores the design onto the screen that's already there, so it keeps its records, its history and any links or extensions pointing at it; fields the backup no longer has simply stop being shown, and their data is kept rather than deleted. Overwriting is only offered between screens of the same type, and importing as a copy stays the default. A backup carries the design only — pages, fields, report blocks, document structure, S/4 links — so a newly created screen starts empty and arrives as Draft, with its own independent store that never writes into the original's records. The fields behind Custom and Document screens are created for you on import; there's no need to open and save the screen afterwards.
Push & Save stops asking S/4 twice for the same refusal. When S/4 turns a field down — "Read-only fields must not be changed", for example — the app now remembers that answer for the rest of your browser session. The next save shows the field in red immediately, with S/4's own wording, without spending the wait; and, more importantly, the field is left out of the request that carries your other changes, so one refused field stops getting everything else rejected along with it. On a measured maintenance-order example this was nearly half the total waiting: a save of four changed fields took 16.9 seconds, of which 8.1 went to two fields S/4 was never going to accept. Nothing is remembered permanently: the memory applies to the exact value that was refused, so correcting the value tries again, and reloading the screen clears it entirely — which matters because some fields are only locked while a document is in a particular status. Changes S/4 accepts are unaffected.
The push progress window now shows where each change's time actually went, next to the total: how long it took to read the record, how long S/4 itself took to apply the change, and how long the check afterwards took — hover the timing for the full detail, including whether the record had to be read back a second time. This matters because "slow" has two very different causes. Waiting for the network is one, and the app can reduce it. S/4 doing the actual work of applying your change is the other — on a maintenance order or a service order that can be several seconds on its own, because S/4 revalidates and reschedules the document, and no change in this app can shorten it. Now you can see which one you are waiting for, per change.
The duplicate message now reads like a sentence. When a save was blocked as a duplicate, the message named the existing record by its internal id — a long string of letters and numbers that means nothing to anyone — and listed the fields by their technical names, for example "ESV_SL_CODE, ESV_PLANT". It now simply says what happened: "Duplicate blocked — another record already has the same Plant Code and Storage Location Code." The fields are named with the labels you gave them in the screen designer, and no id is shown. The same wording is used for the softer "Potential duplicate" question on screens where you are allowed to save anyway, and on SAP-document screens. The screen designer itself is unchanged — the duplicate-check field picker still shows technical field names, as it should.
Push & Save is considerably faster. Changes to different S/4 records — the header and each item row — now travel at the same time instead of queueing behind one another, so a save with several changes takes about as long as its slowest change rather than the sum of all of them. Changes to the same record still go one after another, because sending them together would make them collide. Two more savings: when S/4 refuses a request that carried several fields, the app re-sends them one at a time to find the culprit — it now only does that when S/4 actually looked at the values and objected, instead of also doing it when the request never arrived (server unreachable, timed out, record not found), where it simply tripled the waiting for the same answer. And each change now asks S/4 to return the updated record with its confirmation, which lets the app check what was really stored without a separate follow-up read. Also fixed: when someone else had changed the record first, that was reported as a plain failure — the message from S/4 was being lost on the way back. It is now correctly shown as a conflict, with "Keep mine" and "Use S/4 value" offered on the row as intended.
Two safeguards around Push & Save. First, "Save anyway" is gone from the progress window. It let you store a value S/4 had refused, which is exactly the mismatch this window exists to prevent — your screen would show one value and S/4 another, with nothing to tell you apart. When something is left over you now choose between "Back to editing" and "Use S/4 values & save", and the record is not saved until every S/4-linked change is either accepted by S/4 or dropped in favour of S/4's own value. Second, a fix: changing a key field on a screen makes the app re-read that record from S/4 a moment later, and that re-read used to forget every other change you were still waiting to push. The value stayed on screen so nothing looked wrong, but Save no longer sent it and S/4 quietly kept its old value. The re-read now only clears the fields it actually refreshed.
Custom screens get the same one-click Push & Save, completing the rollout. When you edit a row and change a field linked to S/4, the row's Create/Update button becomes "Push & Create"/"Push & Update": one click sends every changed field to S/4 and then saves the row, with the same progress window used by SAP-document and UDO screens — green for stored, amber when S/4 accepted the request but kept its own value, red when it refused, blue when someone else changed the record first, and "Use S/4 value" to drop a change S/4 wouldn't take. The old "Push all to S/4" pill is gone from the row form; the per-field ⤴ Push button stays. Because saving closes the row form here, anything S/4 didn't accept is now stated in a message after the save instead of passing silently. Also fixed: cancelling a row edit now forgets the discarded changes, so they can no longer be pushed to S/4 by a later save.
UDO screens get the same one-click Push & Save. Open a record, change a field that is linked to S/4, and the Save button becomes "Push & Save" (or "Push & Create" on a new record): one click sends every changed field to S/4 and then saves the record. The same progress window as SAP-document screens shows each change with the time it took and how S/4 answered — green for stored, amber when S/4 accepted the request but kept its own value, red when it refused, blue when someone else changed the record after you loaded it, with "Keep mine" and "Use S/4 value" on the row. Rejected changes can be undone back to the value S/4 holds, and if several fields travelled in one request and S/4 rejected it they are re-sent one at a time so a single problem field no longer blocks the good ones. The per-field ⤴ Push button stays; the old "Push all to S/4" pill is gone, and records with no S/4-linked changes save exactly as before. Also fixed on these screens: cancelling an edit or closing the record now properly forgets the discarded changes, so they can no longer be pushed to S/4 by a later save.
Fixed: "Use S/4 values & save" did nothing for a field S/4 had refused. If you edited a field S/4 won't accept (for example Item text, which comes back as "Read-only fields must not be changed") and then chose "Use S/4 values & save", your refused edit was still written into the record — so the screen showed a value S/4 had never accepted. The reason: when S/4 refuses a change it sends back no values at all, unlike the case where someone else edited the record, so there was nothing to put back. The app now remembers what each field held before you changed it — which is exactly what S/4 still holds after a refusal — and restores that. Refused changes are properly undone and only the changes S/4 accepted are saved. "Use S/4 value" is now also offered on each refused row individually, not just for all of them at once.
Save now pushes to S/4 for you. On an SAP-document screen, the moment you change a field that is linked to S/4 the Save button becomes "Push & Save" — one click sends every changed field (header fields and item rows alike) and then saves the record, so you no longer have to press ⤴ Push on each field first and remember which ones you missed. While it works, a progress window shows each change with the time it took and exactly how S/4 answered: green for stored, amber when S/4 accepted the request but kept its own value (some fields, like equipment validity dates, are managed by S/4 and ignore direct edits), red when S/4 refused it, and blue when someone else changed the record after you loaded it — with "Keep mine" and "Use S/4 value" right there on the row. If several fields travelled in one request and S/4 rejected it, they are automatically re-sent one at a time so a single problem field no longer blocks the good ones. When anything is left over you choose how to finish: save anyway (your edits are kept and the leftover fields stay flagged so you can retry), take S/4's values and save, or go back to editing — and the window tells you plainly which changes already reached S/4, since going back cannot undo those. When everything succeeds it simply closes itself. The per-field ⤴ Push button stays for pushing a single field on its own, and screens with no S/4-linked changes save exactly as before.
The Service Report Compiler can now build a full letterhead — like a classic service-report page. Three additions to ⚙ Layout: (1) a Service call block that automatically pulls in the FSA service call the activity belongs to — its number, subject, problem type, priority, status and reported date — so you no longer retype it; (2) a header date shown in the top-right corner with your own label (e.g. "Datum"); and (3) a footer with up to three columns for bank details, management and registered-office / legal lines, printed on every page above the footer line. All optional — existing layouts are unchanged.
The Service Report Compiler's ⚙ Layout is far more customizable. Page & print: choose the paper size (A4, Letter or Legal), the page margin, an overall text size, the date format (2026-07-27 / 27.07.2026 / 07/27/2026) and whether page numbers print. Tables: on Work time you can pick which columns print, add a totals row (summed hours) and limit it to chargeable time; Materials/Expenses/Mileage can add a totals row too; Checklists can print completed ones only. New blocks: a QR code that deep-links back to the activity or equipment in FSA (or any custom link/text), a fixed Image (diagram, safety notice, stamp), and a Custom fields block for label/value pairs that aren't FSA fields. Branding: a faint diagonal watermark (e.g. DRAFT) on every page, a table style (striped, gridlines or plain) and a logo size. Portability: start a new layout from a built-in preset (Minimal, Inspection, Time & materials), and Export any layout to a file you can Import into another account. Every existing layout keeps working unchanged.
⚡ Extensions is honest about what it doesn't know yet. Outside FSA — the standalone browser view — the product list appears straight from your license, but each product's status and its mobile install link are facts only the server has. The list used to fill those in with guesses: every product showed "Web" and "Active", which read as "this product has no mobile version" even when it does, and hid any product you had deactivated. Those two labels, and the on/off switch that had nothing real to act on, now stay hidden until you enter your credentials and press Load — with a line saying so. Nothing changed inside FSA, which signs you in automatically and has always shown the true status and both Web and Mobile links.
The Extension menu is simpler. Admin ▸ + New ▸ Extension used to list your licensed products — S/4 Live, Attachment Renamer, Checklist Studio, Warranty Checker, Stock Checker, Service Report Compiler, QR Label Studio — next to Solo and Category. Those entries created nothing: each one only handed you an install link you already have under ⚡ Extensions, and only the web one. They are gone, so + New now shows just the two things it actually builds: Solo (one screen) and Category (a group of screens). Nothing was removed from your license — every product still sits under ⚡ Extensions with its web and mobile install links, the install steps, and its on/off switch, and that section now opens by itself when you have no extensions of your own yet.
Date filter boxes are now exactly the same height as every other filter. On iPhones and iPads the date boxes were noticeably taller than the text boxes next to them: Safari draws a date field as its own built-in control that ignored the height set for the filter bar (which is why it always looked correct on a computer). The date fields are now drawn as ordinary boxes, so they match their neighbours exactly — same height, same padding, same text size — while tapping one still opens the usual date picker. Applies to SAP-document and UDO screens.
Dates in the phone filter bar are now full size. Since a date filter got its own row, the date text no longer had to be shrunk to fit — it now reads at exactly the same size as every other filter's text, with normal spacing and the calendar button back, so a date field looks like a proper field instead of fine print. The boxes stay the same height as all the others.
Date filters finally sit right on a real iPhone. On iPhones (and iPads) the two date boxes of a From–To filter were wider than the space they had, so they pushed into the next filter and off the edge of the screen — even though the same page looked correct on a computer, including in a computer's "phone view". The reason: Safari on iOS gives a date box a built-in minimum width that no styling can shrink, and only a real iPhone shows it. So on phones a date filter now gets a row of its own: both dates sit side by side with plenty of room, always fully readable, and they can no longer collide with anything. All other filters keep the usual two-per-row layout, and computers are unchanged.
Date filters now show the full date on computers too. On a wide screen a date-range filter squeezed its two boxes into the same width as a normal filter, so the year was cut off ("24.07.2") and only the calendar icon fit. Date filters now get a slightly wider slot than plain filters — enough for both dates to read in full, with the picker icon — while every box keeps exactly the same height as the rest of the filter bar. Phones are unchanged (two even columns as before). Applies to SAP-document and UDO screens.
Date filters on phones now match their neighbors exactly. A date-range filter (e.g. Requirement date) used to render taller than the other filter boxes, and its two date boxes spilled wider than one field — even off the screen edge. On phones the filter area is now a strict two-column grid where every filter, date ranges included, is exactly half a row: the From–To halves split one field's width evenly, at the same height as every other box, and the full date (e.g. 17.07.2026) stays readable without clipping its last digit. Applies to SAP-document screens; UDO screens (full-width filters on phones) get the same date-box sizing.
Screen designer on phones: the Edit Field dialog now always stays inside the screen. (1) A long S/4 service path (shown once a field is Linked to S/4) used to push the whole dialog sideways out of view — it now wraps onto a second line inside the frame, in the S/4 link, value-help and template pickers alike. (2) In the FSA UDO search-help setup, the UDO / Display Field pair no longer runs past the dialog's right edge — the two boxes share the width evenly and long names shorten with "…". (3) "Scoped from field" and "Match against UDO field" now sit neatly beside each other — the two labels share one line and the two boxes the next (label text is a touch smaller on phones to make room), even when a label needs two lines. (4) The little ⓘ info icon can no longer end up alone on its own line — it always stays glued beside its label — and on phones, pressing an ⓘ now shows its explanation as a readable bar pinned to the bottom of the dialog, fully inside the screen, instead of a bubble running off the edge. Applies to both the document and UDO screen designers.
"Ask this screen" polish. (1) The question box now has a Clear (✕) button — one tap empties it and puts the cursor back, so you can re-ask or dictate again without selecting and deleting the old text first; your applied filters stay put. (2) The From–To date filters no longer balloon taller than the other fields on a phone: the picked date now shows on one line at a size that fits, so a date field lines up with every other filter box.
"Ask this screen" got a major overhaul. (1) It now understands date ranges: "required this month" or "letzte Woche" becomes a real From–To filter on the date field — and date columns in the filter bar now always filter with a From–To date pair instead of a text box. (2) Asking again REPLACES what the previous ask set instead of piling on top — and it's conversational: "davon nur Werk 1010" keeps the date range and adds the plant, "remove the plant filter" does exactly that, while a fresh request starts clean. (3) After each ask, chips show exactly what was applied (hover one to see which words it came from) with a one-click Undo that restores the filters as they were. (4) It's more honest: status words like "open" are never jammed into an unrelated column anymore — if the screen has no status field, it says so plainly, and it no longer invents a sort you didn't ask for. Works in any language, mainly English and German. (5) The dictation mic now appears only on computers — on phones and tablets your keyboard's own mic key types straight into the field (the field hints this), which also works inside the FSA mobile app. When the mic is blocked (e.g. embedded in FSA in the browser), it now tells you instead of silently doing nothing.
Looking for what is coming rather than what landed? That is the roadmap.
Every fix ships to every customer.
One product, maintained across all of it. You get the improvements someone else paid for, and they get yours.