The designer
Altiwerk Studio is two things in one install: a designer where an admin builds screens, and a viewer where everybody else uses them. This page is about the first.
On this page
Who builds screens#
The admin area is where screens are created and configured. It is hidden for users whose role does not grant access, so end users see the screens and not the machinery behind them.
Access can be restricted further to chosen FSA policy groups or roles — useful when “admin” in your tenant is a broader group than the people who should be designing screens.
How a screen is put together#
- Pick a type. Four exist and they are shapes, not tiers — choosing one takes about a minute.
- Define the fields. Sections, pages and fields — each one required, hidden, defaulted, computed or conditional on another field's answer.
- Make them findable. Turn identifier fields into lookups with search help, scoped so the list a person sees could plausibly be right.
- Bring in S/4, if you need it. Bind a field to a live S/4 value, or add a whole live block to a report.
- Tune it for where it runs. Screen settings hold a separate answer for the workspace and for the same screen embedded in a record tab — what is shown, what collapses, which toolbar buttons survive, and whether bulk actions exist at all.
The four types, in short:
| Type | Use it when |
|---|---|
| Standard reports | Answering a recurring question with parameters, where the answer spans more than one object. |
| UDO screens | Data that lives in FSA as a user-defined object and needs more than the admin console gives you. |
| SAP document screens | Anything quotation-shaped: a header with lines, optionally mirroring an S/4 document. |
| Custom screens | A form that is entirely yours, stored as records without you designing storage. |
What one field can do#
Most of a screen's behaviour is configured one field at a time, in a dialog with three groups — on create/edit, behaviour, and data connections, the last of which holds the bottom three rows here. Each has a guide behind it:
| In the field dialog | What it decides | Guide |
|---|---|---|
| On create/edit | Which surfaces show it, and what it starts as | Making a field behave |
| Behaviour | Required, read-only, computed, validated, conditional on another field | Making a field behave |
| Linked to FSA | Pick a record instead of typing an identifier | Search help |
| Auto-fill from host tab | Take the value from the record the screen sits on | Auto-filling |
| Linked to S/4 | Read it live from S/4, every time the screen opens | Binding a field to S/4 |
Check it before your users do#
The screen check runs deterministic checks over the configuration — broken bindings, missing fields, references that no longer resolve — and names what it finds. It always runs; if AI is enabled it will also propose the repair.
The guides#
- Choosing a screen type — Which of the four to pick, decided by the shape of your data.
- Making a field behave — Required, hidden, defaulted, computed, validated — or conditional on another field.
- Search help and value help — Letting people pick a record instead of typing an identifier.
- Binding a field to S/4 — One field, fetched live from S/4, formatted and scoped.
- Bulk CSV import and export — Export a master file, edit it, upload it back — and undo the whole thing.
- Moving a configuration between tenants — Dev to test to production, with a preflight before anything writes.
- Auto-filling from the record a screen sits on — A screen opened on an equipment already knows which equipment it is.
- Tuning a screen for where it runs — The same screen, full size in the workspace and compact inside a record tab.