238 releases, written for you.

The Service Report Compiler has been split into two screens, so designing a report and compiling one no longer fight for the same page. When you open the compiler you now see only what you need to produce a report: the activity, the page itself, and the buttons to download it or attach it back. All the layout settings — the twenty-nine title, logo, footer, watermark, paper and font controls that used to unfold above the page and push it out of sight — have moved behind a button called Edit layout. Press it and the screen becomes a proper designer: every block you can add is listed down the left, your report fills the middle, and the settings for whichever block you clicked sit on the right. Click a section on the page to configure it; there is no list to hunt through any more. Clicking a block in the left-hand list does not add it — it marks it and offers you two choices: Show details, which explains what that block prints and which fields it carries without touching your report, and Add to report, which puts it in. The details panel carries its own Add button, so you can read first and decide after. Dragging a block from the left straight onto the page still adds it where you drop it, and dragging a section moves it. Blocks that print nothing on the activity you picked — a Mileage table with no rows, say — now show as a faint outline instead of vanishing, so you can still reach and remove them, and the designer opens with the page already drawn even before you have picked an activity. A new Preview button (also on the compile screen) opens the finished report full screen with nothing else around it; close it with Escape or the Close button. Nothing about what the PDF contains has changed, and every layout you have already saved opens and prints exactly as before. Two fixes to the page itself. A block set to full width now really does run the whole width of the page — until now it quietly shrank to fit its text, which is why reports left the right-hand side of the paper empty; the PDF was always correct, so it is the preview that has caught up. And label-and-value blocks such as Service summary, Customer and Equipment can now be laid out three different ways, which is what fills that width. Select the block and you will find Field layout: List keeps the label beside its value, the way reports have always printed, and reads best for a few fields with long values such as an address; Columns puts the label above its value in a tidy grid, which suits a block carrying many short fields; and Table prints the labels as a header row with the values underneath, styled like the other tables in your report. For List and Columns you also choose how many fields go on each line, one, two or three. Reports you have already saved keep the List layout with one field per line and are completely unchanged. Reports you have already saved keep printing one per line and are completely unchanged. Finally, you can now decide where a block sits by dragging it: drop it on the top or bottom of another block to place it above or below, or drop it on the left or right edge to stand the two side by side on the same line. The edge you are about to drop on lights up as you drag. On a phone the settings arrive as a panel from the bottom of the screen when you tap a block, so the page stays visible while you change it.

The mobile app now shows the Altiwerk logo instead of a lightning-bolt emoji. Altiwerk Mobile, the app you open from the SAP FSA mobile client, still had a small yellow lightning bolt next to its name in the top bar — left over from before the app was called Altiwerk. It now shows the same AW mark you see in Altiwerk Studio, and it lightens automatically when your device is in dark mode. The browser tab icon was also missing a fallback image, which is why some browsers kept showing the old bolt even after the app icon had been updated; that fallback is now in place. Nothing about how the app works has changed — this is appearance only. If your browser still shows the old icon after this update, reload the page once with a hard refresh, or fully close and reopen the app.

Screen backups are no longer named after the app's old name. Pressing Export in Back up & restore screens used to hand you a file called esv-screens-2026-08-09.json — 'esv' being EasyScreenViewer, what this app was called before it became Altiwerk Studio. The file you download is now called altiwerk-studio-screens-2026-08-09.json, and a single-screen export is altiwerk-studio-screen-Inspection_Form-2026-08-09.json. Only the suggested file name changed. What is inside the file is exactly the same, so a backup you exported earlier under the old name still restores normally — there is no need to re-export anything, and if you have renamed your downloads yourself, restore does not care what the file is called.

The uninstall and reinstall that release 1.5.205 asked you to do is cancelled — you do not need to do anything. That release changed the extension's short technical name from 'altiwerk-studio' to 'studio', so that the address FSA builds would read altiwerk-studio instead of repeating the word twice. FSA fixes that name when an extension is installed and never reads it again, so the only way to get the shorter address was a full uninstall and fresh install. On reflection that is not worth asking anyone to do: an uninstall means placing the extension again and entering the licence key again, and all it buys is a tidier address that nobody types. The name is therefore back to 'altiwerk-studio', which is what every existing installation already carries. The address keeps the repeated word, and that is now a deliberate choice rather than an oversight. Nothing about the app, your screens, your data or your licence is affected either way.

The description FSA shows for Altiwerk Studio has been rewritten, because it had fallen behind the product. It still described three kinds of screen and said nothing about SAP S/4HANA — which had been the point of the app for months. The entry you now see under General Information in FSA names all four screen types, says what each one actually gives you (filters, saved views and Excel export on report screens; CSV import on UDO screens; header and items on SAP document screens; and forms you define yourself), and mentions the two things a reader most needs to know before installing: that a screen picks up the record it is opened on by itself, and that screens can read and write live S/4HANA data if your licence includes it. It also says that any screen you build can be published as its own installable FSA extension. Nothing in the app changed — this is the catalogue entry only. FSA reads the description from our manifest each time it checks for an update, so an already-installed Studio will show the new text once FSA next reads it; the app's name and address are untouched and no reinstall is needed.

Altiwerk Studio now opens in light mode by default. Until now it followed your computer's appearance setting, so if your Mac or Windows was set to dark, Studio opened dark too — inside FSA, that meant a black panel sitting in the middle of FSA's own white screen, without anyone having chosen it. Light is now simply the default. Dark mode has not gone anywhere: the sun/moon button in the top right still switches it, and once you press it your choice is remembered from then on, on that browser. One thing to expect if you were deliberately using dark mode: this release resets that once, so you will need to press the button one more time and it will stick after that. The reason is that the old version quietly saved your computer's setting as though you had chosen it yourself, and there was no way to tell those apart from a real choice. The mobile app is unaffected and still follows your phone's appearance setting, because phones do not pass that information through any other way.

Altiwerk has a real logo, and it is now in the top bar. The lightning-bolt placeholder is gone, replaced by the AW mark — a ligature where the A and the W share one diagonal stroke, so they read as a single drawn glyph rather than two letters side by side. The mark takes its colours from the theme, which means it reverses itself correctly in Evening Horizon dark instead of needing a second image. The browser tab icon changed too: Studio now shows an A on a Horizon-blue tile, and the mobile app's home-screen icon matches it. The mark has also taken over every lightning bolt that stood for the extension feature: the Extensions button above the screens list, the title of the Extensions dialog it opens, the Create extension button on a screen you have selected, and the Extension tile you pick when creating something new. Nothing about how the app works has changed — this is purely what it looks like.

The app now says FSA everywhere it used to say FSM. SAP renamed Field Service Management to Field Service and Asset Management, and while the newer parts of the app had followed, the older ones had not — so the same product was called two different things depending on which dialog you happened to open. Every message, label, placeholder, warning and confirmation you can see now says FSA: the dialogs that create a UDO or a field, the SAP-document and report designers, the record viewers, the upload hints, and the error messages that come back when something goes wrong. That includes the small help bubbles behind the ⓘ icons — the tooltip explaining what 'Auto-fill from host tab' does, the one describing which object hosts a solo screen, and the notes on the S/4 quick-lookup screen. Nothing about behaviour changed. Names SAP itself still uses are untouched, because they are not ours to rename — UdoMeta and UdfMeta are the actual names of the things being described, and the technical pieces underneath keep their original names for the same reason.

The mobile app is now Altiwerk Mobile, and a naming bug in the screen designer is fixed. On your phone the app was still called ESV Mobile — in its title bar, in the browser tab, and under the icon once you install it to the home screen; it is Altiwerk Mobile everywhere now, and a few messages inside it that pointed you at 'ESV Admin' now name the app properly. The bug is worth knowing about if you create your own tables or fields: when the app's reserved name prefix changed to ALTI_ in an earlier release, the two dialogs that create a UDO or a UDF kept showing the old ESV_ prefix beside the box you type in. What they created was always correct — the objects really were named ALTI_ — but the dialog told you otherwise, so a name you expected to be ESV_ORDERS was in fact ALTI_ORDERS. The dialogs now read the prefix from the same single place the app uses when it creates the object, so the two can no longer disagree. Two other screens that named a storage table in passing were showing the old name for the same reason and are now correct too.

Follow-up to the rename: the last places still showing the old names now show the new ones, and the extension's address inside FSA is tidier. The install manifests that FSA reads — the ones behind every product's install link — still said Checklist Studio and QR Label Studio, and named the old product as the publisher; they now say Checklist Manager, QR Labels, and Altiwerk. The mobile app's own name, the one your phone shows under the icon when you install it, was still ESV Mobile and is now Altiwerk Studio. Several messages inside the mobile app that mention your licence were still using the old product name too. ⚠ One change needs action from you: the extension's short technical name in FSA is now simply 'studio' rather than 'altiwerk-studio', because FSA builds the address from the publisher and that name together and was repeating Altiwerk twice. The address now reads altiwerk-studio. FSA fixes an extension's technical name when it is installed, so this one does need an uninstall and a fresh install from https://studio.altiwerk.com/appconfig.json — the name you see in the app and in the FSA catalogue is unchanged either way.

Three products have new names. The app you are reading this in is now Altiwerk Studio — it was Easy Screen Viewer. Checklist Studio is now Checklist Manager, and QR Label Studio is now QR Labels. Nothing about how any of them work has changed: same screens, same licence, same install, same data. The old name simply described the product by what it showed rather than what it lets you do, and it carried a promise about being easy that got in the way of what the thing actually is — a place where your own people build the screens your team needs. The two other names moved so that 'Studio' means one thing rather than three; Checklist Manager is also just a truer description of a tool whose job is versions, usage and translations. Any link or bookmark you already have still works. (A reinstall IS needed — see 1.5.205, which finished this rename.) If your organisation keeps its own documentation or training material, that is the one place the old names will linger until you update them. The app's own address moves with the name too — it is now studio.altiwerk.com, and if your organisation restricts which addresses its browsers may reach, that is the one to allow alongside pwa.altiwerk.com for the mobile version.

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 studio.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.

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.