Accredo Saturn’s screens are not fixed.
Form Designer is the tool inside Saturn that changes them. A scripted form is a custom screen — a data entry form, a maintenance grid, a dashboard — laid out in Form Designer with MaxBasic behind it, running inside the product with its own data, lookups and permissions rather than beside it.
Personal reply from Andrew within one business day.
What is a scripted form in Accredo, exactly?
A scripted form is a custom screen built inside Accredo Saturn with its Form Designer — a layout of panels, fields, grids and buttons saved as a form file on the install, with MaxBasic code attached to the things a user does on it.
The word doing the work in that sentence is inside. A custom form is not an application that talks to Saturn; it is a screen that is Saturn, drawn by the same product, reading the same data through the same access layer, subject to the same user permissions. When somebody picks a customer on a custom form they are picking the customer, not a copy of one, and when the form writes, it writes where every other Saturn screen writes. That single property removes a whole category of problem — the copy that drifted, the sync that stopped, the two systems that disagree about who owes what — before any code is written.
There are two shapes of form and they are built quite differently. The first is a maintenance form: a screen bound to a table, where the layout exists to make one record pleasant to create, find and edit. The second is an assembled form: a screen with no single record behind it, which gathers a working set from several places into memory when it opens, shows it, and acts on what the user does with it. Dashboards, reconciliation screens, selection tools and anything that answers a question rather than editing a thing are the second kind. People asking for a form usually mean the first and often need the second, and establishing which is a conversation worth having before anything gets drawn.
The code lives on events, not in one script body. A form is a set of named components, and the ones that matter each have moments they can report: this form has opened, this field has changed, this button was pressed, this row was added, this value is about to be committed. Code attaches to those moments individually. It is the same MaxBasic that event and batch scripts are written in, against the same data, but the trigger surface is the form rather than Saturn’s save-and-post cycle — which means a form can afford to be as forgiving as you like, because nothing in the ledger has moved yet.
A form is presentation; a field is storage. This distinction derails more scoping conversations than anything else on this page. If the requirement is that a new piece of information gets captured against a record and stays with it, that is a custom field, and it will appear on the standard screen without any custom form existing at all. A form is what you build when the arrangement is the problem — when a job takes four screens and should take one, when the sequence is wrong, when the person doing it has to hold six facts in their head that are not on the screen in front of them. Build the storage first, and the screen only if the arrangement is still wrong afterwards.
None of this makes a custom form exotic. It is the ordinary way a mature business system lets you fit it to a process it was not specifically written for. The skill is not in the drawing. It is in knowing which of Saturn’s own screens already does the job, what the form has to validate before it lets anything through, and what happens on the day the person it was built for leaves.
What can a Form Designer form actually do?
More than most Accredo sites realise, and less than a web application. A form is built from containers, fields, grids and buttons; behind each of them sits an event that code can attach to. The layout is the quick part. What the form checks before it lets anything through is the work.
// A form nobody can get wrong is worth more than a form that looks good.
Layout is containers inside containers. Panels anchor to the edges of the form and to each other, so a screen can be resized without the fields sliding into one another. Tabbed sections keep a long form to one visible page at a time, which matters more than it sounds — a screen that scrolls is a screen where the field at the bottom gets missed. Grouped frames and separators do the rest. It is unglamorous and it is most of what makes a custom screen feel like part of the product rather than something bolted to it.
The input components are ordinary; the lookup components are not. Text, numbers, dates, checkboxes and static dropdowns behave the way they do everywhere. What distinguishes a Saturn form is the field bound to a live table: the user types or selects, the product resolves it against real records, and the form gets back an actual reference along with anything else it wants to display from that record. A screen that shows the customer name next to the code the moment the code is entered catches a wrong code at the point of entry rather than at the point of invoicing, and that is the difference between a form that reduces errors and a form that merely relocates them.
Grids are where multi-line work happens. An editable grid gives a user rows to work through — lines to allocate, quantities to confirm, exceptions to clear — with the right editor appearing per column and a navigator for inserting and removing rows. A read-only grid does the same job for output. Either can be driven from a table on disk or from a working set the form assembles in memory when it opens, and that second option is what makes selection screens and reconciliation tools possible without writing anything to disk until the user commits.
Charts, timers and buttons finish it. A chart component plots whatever the form has in memory. A timer lets a screen refresh itself on an interval instead of waiting to be told. Buttons carry shortcut keys, so a high-volume screen can be driven from the keyboard by somebody who uses it forty times a day and should never have to reach for a mouse. That combination — assemble a working set, plot it, refresh it on a timer — is the whole basis of a dashboard that lives inside Saturn, which is the next question and a genuinely contested one.
Should a dashboard live inside Saturn or in a browser?
Both are real options and XBA builds both, so the question is not which is better but who the numbers are for. The deciding factor is almost never technical. It is whether the people who need to look at this already have Saturn open.
| A form inside Saturn | A browser dashboard | A report you run | |
|---|---|---|---|
| What it is | A Form Designer screen that assembles figures when it opens and refreshes itself on a timer. | A web page reading Saturn data through a supported route and rendering it in a browser. | Output produced on demand or on a schedule, read once and set down. |
| Who can see it | People with Saturn open and the rights to that data. Nobody else, which is sometimes exactly right. | Anyone you give access to, on any device, without a Saturn seat or any Saturn knowledge. | Whoever the output is sent to, including people who will forward it onwards. |
| How fresh the numbers are | As live as it gets. The form is reading the working data in place, with no copy in between. | As fresh as the route allows — usually live on request, occasionally cached deliberately for speed. | Correct at the moment it ran, and quietly wrong from then on. |
| What it can combine | Saturn data. Reaching outside the product from a form is possible but it is not what the form is for. | Saturn plus anything else you run — the CRM, the website, the freight provider, a spreadsheet nobody will give up. | Whatever was assembled when it was written, in the shape it was written in. |
| What it costs to own | Part of the install. Survives on the Saturn server, needs nothing hosted, and is upgraded with everything else. | Something to host, secure and keep running — small, but not nothing, and it is a second thing to look after. | Almost nothing, until the definition changes and every saved copy of it is now misleading. |
| Best for | Operational people already in Saturn all day who need one screen to stop asking the same question. | Managers, owners and branch staff who never open Saturn, and for anything that has to work on a phone. | A figure somebody genuinely needs once, or a record of what was true at period end. |
// Already in Saturn all day? Build it in Saturn. Never opens Saturn? Build it in a browser. Needs it once? It was a report.
The mistake worth avoiding is building the wrong one because of who asked. A request for "a dashboard" from somebody in the warehouse and the same request from somebody in the boardroom are different builds, and answering both with the same artefact means one of them ends up with a screen they have to be trained into or a login they will not use. Ask who looks at it, how often, and on what — three questions, and they settle it more reliably than any argument about capability.
The second mistake is subtler and more common: building a dashboard when the underlying figure is not agreed. A screen that shows a number to eight people mostly succeeds in getting eight people to disagree about it in public. If two parts of the business already calculate margin differently, a dashboard does not resolve that, it publishes it. The definition work comes first and it is genuinely the harder half — which is the argument the data and reporting page makes at length, and it applies whichever side of this table you land on.
Where a browser dashboard is the answer, how it reaches the data becomes its own decision, and the routes are set out on the Accredo API and OData integration page. Where the requirement turns out to be a small application rather than a screen of figures — something people enter work into, not just read — that is a custom app, and the warehouse and field examples on the Accredo hub are the shape it usually takes.
How do invoice and packing slip layouts get changed?
A printed document in Saturn has two separable halves: the layout, which decides what appears on the page and where, and the logic, which decides what the document is allowed to say in the first place. Most requests are the first half, and the first half is much cheaper.
Start by finding out which half you are in. "The packing slip needs the customer order reference at the top" is a layout change: the information already exists on the record, and the job is to put it on the page, in a position, at a size, that a person in a warehouse can read at arm’s length. "The packing slip should not show pricing for these customers but should for those" is not a layout change — it is a rule, it needs somewhere to be decided, and the document has to ask something at print time. Those two requests sound alike in a meeting and differ by an order of magnitude in effort.
Layout work is genuinely worth doing well. Documents are the part of your system your customers actually see, and a lot of Accredo sites are running layouts that were adequate on the day they went live and have accumulated a decade of small wrongness since — a logo at the wrong resolution, a remittance address that moved, a column that made sense when there were three product lines, whitespace where the terms should be. None of it is difficult. All of it is the impression your invoice makes on somebody deciding whether to pay it this week or next.
Logic at print time belongs on the print event, and it belongs there carefully. Where a document has to decide something — which layout a given customer gets, whether a line is suppressed, what a conditional block says — that decision runs as a script attached to the moment the document is produced. The rule that keeps this clean is that printing is a read: producing a document should not change the data the document describes. A document that writes when it prints behaves differently depending on how many times somebody previewed it, and that is a defect discovered months later during a reconciliation, by somebody who has no idea a script exists. The event hooks section of the scripting page takes that hook alongside the other three.
The honest default is to change the layout and leave the logic alone. A surprising share of document requests are satisfied by a field that is already on the record and simply is not on the page, or by a second layout selected manually for the handful of cases that differ. Both are cheaper to build, cheaper to explain, and much cheaper to unpick in three years than a conditional rule nobody remembers agreeing to. Reach for the script when the branching is genuinely per-transaction and genuinely frequent — not because it is more elegant.
When is a custom form the wrong answer?
Often enough that it is worth asking before quoting. Four cases account for most of it, and the first two are where nearly all the wasted money goes.
When the standard screen already does it. Saturn’s own screens have years of behaviour in them that nobody itemises — the validation, the permissions, the lookups, the small courtesies that stop people making mistakes. A custom form that recreates one of them inherits none of that for free and takes on all of it as an obligation. A meaningful share of form requests turn out to be for a standard screen somebody has not been shown, or for a setting on it that was never switched on. The hour spent checking is the cheapest hour in the project.
When the people using it are not Saturn users. This is the big one, and it is a licensing and training question rather than a technical one. If the person who needs to enter this works in a warehouse, in a van, on a phone, or at a customer site, then a screen inside Saturn is the wrong artefact no matter how well it is built — they will not have it open, and putting them in front of it means a seat, a login and training in a product they otherwise never touch. That is when the answer is a small purpose-built application that posts into Saturn, and it is a different conversation with a different budget.
When it is really a report. People ask for a screen when what they want is a number. A screen implies looking, and looking implies somebody whose job includes looking — which is a real cost and frequently not one anybody has budgeted. If the requirement is that a figure gets to a person once a week, that is output on a schedule, and building a screen for it creates a thing that has to be maintained forever so that somebody can remember to open it.
When it would become a second system. The failure mode to watch for is a form that starts storing its own version of something Saturn already knows — its own status field, its own copy of a price, its own list of who is allowed to do what. It is always convenient at the time and it is always the thing that has to be reconciled later. If a form needs to record something new, that is a custom field or a custom table sitting properly inside Saturn with everything else, not a private copy the form maintains on the side.
What does a scripted forms project involve?
Less drawing than people expect and more watching. The layout is usually a day; the validation rules behind it are the build; and the part that determines whether the form is still in use in three years is the handover.
It starts by watching somebody do the job on the screens they have now. Not a description of the job in a meeting — the job, at the desk, with the interruptions and the sticky note on the monitor and the spreadsheet they alt-tab to. Almost every custom form worth building is justified by something that shows up in that twenty minutes and never comes up in the meeting: the field they always tab past, the second screen they open every single time, the value they copy by hand because the two things that need it were never on the same page.
What follows is deliberately ordinary. Agree what the screen has to prevent, not just what it has to capture, because a form’s value is mostly in what it refuses. Draw the layout and put it in front of the person who will use it while it is still cheap to move things — a form is one of the few pieces of software where the user can give you useful feedback on day one, and not using that is a waste. Wire the live lookups so wrong references are caught at entry. Then build it against a copy of the company file, prove it against the awkward cases as well as the obvious one, and only then put it near the live install.
What you end up with is the form file, the code behind it, and a document that says what it does, what it deliberately does not do, and how to take it off again. The source is yours. Nothing about it changes your licensing or your upgrade path, and coordinating with whoever maintains your Saturn install is normal rather than awkward. For the wider picture, the Accredo Saturn capability page covers the scripting, custom tables, pricing rules and reporting this sits beside, and where a form turns out to be the wrong artefact entirely, the field service management case study is what the alternative looks like built out in full.
Got a job that takes four Saturn screens and should take one? Describe it — the audit is free, and sometimes the answer is that a standard screen already does this.
Book a free process auditQuestions about Accredo forms and documents.
What is Form Designer in Accredo?
Form Designer is the tool inside Accredo Saturn for building custom screens. You lay out panels, fields, grids and buttons, bind the fields to Saturn data, and attach MaxBasic code to the events those components raise — a form opening, a field changing, a button being pressed. The result is a form file on the install that runs as part of the product, with the product’s own data access and user permissions.
What is the difference between a custom field and a custom form in Accredo?
A custom field is storage: a new piece of information held against a record, which appears on the standard screen and travels with the record into reports. A custom form is presentation: a screen that arranges existing information differently, usually because a job currently spans several screens or requires knowledge that is not visible on any of them. If the requirement is to capture something new, start with the field. Build the form only if the arrangement is still wrong once the storage exists.
Can Accredo Saturn show a live dashboard?
Yes, in two different places, and the choice matters. A dashboard built as a Form Designer screen assembles its figures when it opens and can refresh itself on a timer — ideal for operational people who already have Saturn open all day, and it needs nothing hosted. A browser dashboard reads Saturn data through a supported route and works for anyone with a link, including people who have never opened Saturn and people on a phone. The deciding question is who is looking, not which is more capable.
Can we change what prints on an Accredo invoice or packing slip?
Yes, and it is usually cheaper than expected. Separate the layout from the logic first. Adding, moving or resizing something that already exists on the record is a layout change and is the majority of requests. Making the document decide something at print time — which customers see pricing, when a block is suppressed — is a rule, and it runs as a script attached to the print event. The constraint on that script is that printing is a read: producing a document should never change the data the document describes.
Will a custom form survive an Accredo upgrade?
A form built against the product’s supported surface should, and the layout is the least fragile part of it. What needs watching is the code behind the form, on the same terms as any other script: written against documented behaviour it carries through, written against something the product never promised it breaks, and it tends to break quietly. Either way the answer is not to hope. The form file and its code are version-controlled and documented so an upgrade is a test you run rather than a discovery you make.