Your data does not have to live beside Saturn.
Accredo Saturn takes your own storage in two places: a custom field on a record the product already keeps, and a standalone custom table of your own. Both are defined in Table Designer, both sit in the company data with Saturn’s own tables, and both inherit the same permissions and the same backup as everything else.
Personal reply from Andrew within one business day.
What are custom tables and custom fields in Accredo?
A custom field is a piece of your own information added to a record Accredo Saturn already holds, appearing on that record’s standard maintenance screen. A custom table is a record type Saturn does not have at all, defined by you and stored in the company data alongside the product’s own.
Both are built with the same tool, and the distinction between them is the first thing worth getting right, because it is the one that is expensive to change afterwards. A custom field extends something: it attaches to a record that already exists, travels with it, and is visible wherever that record is. A custom table creates something: it has rows of its own, keys of its own, and no natural home on any existing screen until you give it one.
The important word in both cases is inside. This is not a database sitting next to your ERP with a job scheduled to keep the two in agreement. The definitions become part of the company data — covered by the same nightly backup, restored by the same restore, governed by the same user permissions, and available to the same queries as the ledger they sit beside. That property is the entire argument for doing it this way, and it is why the spreadsheet that currently holds this information is not a like-for-like alternative no matter how well maintained it is.
A custom field is cheaper than people expect and a custom table costs more than people expect. Adding a field to an existing record is close to free: defined once, it appears on a dedicated tab of the standard screen, and nothing else has to be built for somebody to start using it that afternoon. A custom table is a genuine small build. The table itself is quick; the keys, the register entry, the way people put data into it and the definition of what a row actually means are the work, and skipping any of them produces storage that technically exists and practically does not. Both, though, are easier to add than to justify — every field created is a field somebody has to fill in, keep true, and eventually explain to whoever inherits the job.
Custom field or custom table — which does a requirement need?
Almost every case is settled by two questions, and neither is technical. How many of these can one record have? And does the thing have a life of its own, or does it only exist as a property of something else?
| A custom field | A custom table | A system beside Saturn | |
|---|---|---|---|
| What it is | Your own information held on a record the product already keeps, shown on that record’s standard screen. | A record type the product does not have, defined by you and stored with Saturn’s own tables. | A spreadsheet, a database or a product of its own, holding the data outside the ERP entirely. |
| What it fits | Exactly one value per existing record — a classification, a reference, a date, a flag that qualifies something. | Things that come in multiples per record, or that are created, amended and retired on their own schedule. | Data the ledger genuinely has no interest in, or that already belongs to a system which owns it properly. |
| What you get without building anything | A place on the standard screen, inclusion in queries and reports, and the record’s own permissions and backup. | Storage, keys and a register entry. A way for people to get data in and out is a separate piece of work. | Whatever that tool already does well, immediately, with no definition work inside Saturn at all. |
| What it will not do | The product will not make it compulsory, will not auto-number it, and will not enforce that a value appears only once. | Nothing shows it to anybody by itself. Unregistered and without a screen, it is data with no doors on it. | It will never appear in the same query as the ledger, and holding the two in step becomes a standing job. |
| What it costs to own | Close to nothing. It is upgraded with the record it sits on and there is nothing separate to look after. | A definition to keep true, a screen to keep working, and a schema that has to be changed carefully. | Cheapest thing in the building to start, and reliably the most expensive to have started. |
| Best for | Anything that qualifies a customer, product, job or document and has exactly one answer. | Agreements, schedules, registers, entitlements — several rows per thing, with rules of their own. | Something that is honestly not the ERP’s business, in a system that honestly owns it. |
// One value per record? A field. Many rows with their own lifecycle? A table. Nothing to do with the ledger? Then not in the ledger.
Ask “can there ever be two?” once, early, and mean it. This single question prevents most of the expensive mistakes on this page. A field is the obvious answer when somebody needs to record which scheme a customer belongs to, and it is the right answer right up until the day a customer belongs to two schemes with different start dates. At that point the field is holding a comma-separated list, three reports are quietly wrong, and the migration is a project rather than an afternoon. The cost of asking is thirty seconds; the cost of not asking is paid in eighteen months by somebody else.
The second question is about ownership rather than volume. Some information only exists as a property of something else: a customer’s delivery instruction has no meaning without the customer. Other information has a life of its own — an agreement is negotiated, starts, gets amended, expires, and is referred to long after the person who signed it has gone. Anything with its own dates, its own status and its own history is a table, even when it currently has one row per customer, because a thing with a lifecycle eventually needs a record of that lifecycle.
Where the answer comes out as the third column, that is not a failure. Plenty of data has no business in an ERP, and putting it there because the ERP is where everything else lives is how a general ledger ends up holding somebody’s prospect list. One source of truth per type of data, wherever that source correctly sits — which is an integration question rather than a storage one, and the systems and API integration page takes it properly.
What does a custom field do that a spreadsheet column cannot?
Three things, and the third is the one that surprises people: a custom field defined consistently across a chain of documents is carried forward by the product as the paperwork moves, so a reference captured at order entry is still attached to the ledger transaction months later.
It appears on the screen people already use. A custom field lands on a dedicated tab of the record’s standard maintenance screen, and that tab can be arranged — fields grouped, ordered, split across sub-tabs, set read-only for the people who should see but not change them. There is no form to build and no training beyond telling somebody the tab exists. For a large share of “we need to record this” requests that is the entire job, and it is worth establishing before anybody scopes something bigger.
It is real storage, so everything downstream can see it. The value goes into the same queries as the rest of the record, so it can be reported on, filtered by and used as a condition in a script without anybody exporting anything; it is subject to the record’s permissions, so a field only two people should see can be; and it is inside the backup, which the spreadsheet on the shared drive is not in any sense that will comfort you at the time it matters. It is also worth defining as a lookup against a list you control rather than as free text, because that is the difference between a field you can group a report by and a field holding four spellings of the same thing.
It travels with the paperwork. Where the same custom field is defined consistently on a document and on the documents generated from it, Saturn carries the value forward as the chain runs — from an order to the invoice raised against it, from that invoice to the transaction it posts into the ledger. Nothing has to be scripted to move it. That is what makes a custom field the right way to attach a job reference, a contract number or a delivery instruction that has to survive all the way to a statement, and it is the strongest practical argument for putting the field inside Saturn rather than tracking it alongside.
The constraints are real and belong in the estimate rather than in the surprise. A field added to one of the product’s own records cannot be made compulsory by ticking a box — where the business rule is that it must always be filled in, that rule is enforced in script when the record is saved, which is an event script rather than a definition. It cannot be an auto-numbering field. And an index added over a product record can make searching fast but cannot enforce that a value appears only once. None of these is a blocker; all of them are the difference between a five-minute answer and a day of work.
What does a properly built custom table need?
Five things, and only the first is what people picture when they ask for a table. A table that has been defined but not keyed, registered or given a way in is not finished — it is storage nothing can reach, which is worse than not having built it.
-
01
Model it
Decide what exactly one row represents, and say it in a sentence somebody in the business would agree with. Everything else follows from that sentence.
breaks here if: a row means two things, and the table needs splitting once it has data in it -
02
Key it
Give it one field that identifies a row and nothing else, indexed as unique and primary — the requirement anything reading it from outside will assume is already there.
breaks here if: the key is a business value that later changes, or there is no single one at all -
03
Register it
Registration is what makes the table visible to reporting queries, usable as a lookup source on other screens, and available to a Navigator shortcut.
breaks here if: it is skipped, and the data is real but nothing else in Saturn can find it -
04
Give it a way in
A maintenance shortcut is enough for a small reference list. Anything people work in daily wants a form built for the job it is actually used for.
breaks here if: the only route in is a raw editor, and the data ends up entered by whoever is brave -
05
Prove it on a copy
Schema changes are applied against a copy of the company file first, always, and the definition is version-controlled so the next change starts from a known state.
breaks here if: a schema is reapplied in place and takes the columns it did not know about with it
Step two is where the integration project you have not scoped yet gets decided. If anything outside Saturn will ever read or write this table — a web dashboard, a warehouse app, a reporting tool — it needs exactly one field that identifies a row uniquely, indexed as both unique and primary. That is not an XBA preference; it is what the web service requires before it will publish the table at all. Retrofitting it onto a table that already has rows, keys and screens attached to it is an unpleasant afternoon, and five minutes at the start avoids it entirely. The routes that consume it are on the Accredo API and OData integration page.
Step five is the one that can destroy data, so it gets stated plainly. Table definitions can be applied from a saved schema, which is the right way to move a change from a test system to a live one. What that operation does is make the table match the schema — and anything present on the table but absent from the schema is dropped, along with everything stored in it, permanently, indexes included. It is a correct and useful mechanism being used carelessly, and it is why every change here is proven against a copy of the company file first.
Two small decisions cause trouble years later. Custom definitions are namespaced with a reserved prefix so they can never collide with something the product introduces in a future release, and skipping that convention is how an upgrade becomes an argument. And a table name has to stay plain — letters, digits and underscores — because punctuation in it breaks the metadata the web service publishes. Both take ten seconds at definition time and surface two years later as an integration that cannot see the table, by which point nobody remembers making them.
Where the way in needs more than a maintenance grid — validation as somebody types, a screen laid out around the job rather than around the table — that is a scripted form, and it is the usual companion to a custom table rather than an exception. Where the people entering the data do not use Saturn at all, the table can still be the right storage while the way in is a small purpose-built application posting into it.
When should the data not go into Saturn at all?
More often than an ERP consultant is supposed to say. Four cases account for nearly all of it, and the first quietly does the most damage.
When nobody has agreed what it means. A field with no agreed definition is a column that gets filled in three different ways by three people who are all being reasonable — somebody records the date it was promised, somebody the date it was requested, somebody the date they typed it in, and a year later a report built on it is confidently wrong. The definition is the work. If it cannot be written in one sentence that two people from different parts of the business both accept, the field is not ready to exist, and that is the same argument the data and reporting page makes at length.
When another system already owns it. If the CRM owns the relationship and the pipeline, the ERP should not hold a second version of them. A shadow copy always begins as a convenience — just this one field, so we can see it here too — and always ends as two systems disagreeing in front of a customer.
When it is one person’s working notes. Not everything is a record. A free-text field that exists so somebody can type whatever they like accumulates conventions rather than data. If the purpose is to leave a note for a colleague, a note is fine; if the purpose is to count something later, free text will not do it, and a list of valid values is the whole difference.
When the volume belongs to a process, not to the ledger. A process generating thousands of events a day — scans, readings, movements — does not need every one of them inside the accounting data to be useful. Ask what the ledger needs to know rather than what the process produces; usually that is the summary and the exceptions, and the raw stream stays where it is generated.
What does a custom tables project involve?
The building is small and the agreeing is not. Defining a table is an hour; establishing what one row means, who maintains it and what happens to the spreadsheet it replaces is most of the engagement, and it is the part that determines whether the data is trustworthy in two years.
It starts with the spreadsheet. There is nearly always a spreadsheet, and it is the most useful artefact in the room — a working specification written by the people who actually need the data, complete with the exceptions they have accommodated over the years. Reading it properly, and asking about the columns that are inconsistently filled in, surfaces the modelling questions faster than any workshop. The awkward column is usually the one that proves the requirement is a table rather than a field.
From there it is deliberately ordinary. Write the one-sentence definition of a row and get it agreed by somebody who does not report to whoever asked for it. Decide what is a field on an existing record and what needs a table of its own, using the two questions above rather than by preference. Define it, key it, register it, and give it a way in that suits how often the data actually changes — a reference list maintained twice a year does not need what a daily working screen needs. Then load the existing data, which is where the disagreements in the old spreadsheet finally have to be resolved, and expect that to take longer than the build.
What gets handed over is the table definitions, the schema files they were built from, whatever screen or shortcut maintains them, and a document saying what a row means, who owns the list of valid values, and how to change the definition safely. The definitions are yours, and nothing about them changes your licensing or your upgrade path. For how this sits beside the rest of the toolbox, the Accredo Saturn capability page covers the scripting, forms, pricing and reporting it works with, and the field service management case study is what it looks like when custom storage, a form and an integration are built as one thing.
Running a spreadsheet the business depends on and Saturn knows nothing about? Describe it — the audit is free, and sometimes the answer is one field on a screen you already have.
Book a free process auditQuestions about Accredo custom tables and fields.
What is the difference between a custom table and a custom field in Accredo?
A custom field is added to a record Accredo Saturn already keeps and holds one value against it, appearing on a dedicated tab of that record’s standard maintenance screen. A custom table is a record type Saturn does not have, defined by you, with its own rows and keys. The deciding question is how many of these one record can have: exactly one means a field, more than one means a table. The second question is whether the thing has a lifecycle of its own — its own dates, status and history — because anything that does will eventually need a table even if it starts with one row per record.
Can you add custom fields to Accredo’s standard screens?
Yes. A custom field defined against one of the product’s own records appears on a dedicated tab of that record’s maintenance screen without any form being built, and that tab can be arranged — fields grouped and ordered, split across sub-tabs, or set read-only for people who should see them but not change them. It is the cheapest customisation in Accredo Saturn and it satisfies a large share of requests that arrive described as something much bigger.
Will custom tables and custom fields survive an Accredo upgrade?
They are designed to. Custom definitions are namespaced with a reserved prefix precisely so they cannot collide with something the product introduces later, and they live in the company data rather than in the product’s program files. The risk is not the upgrade itself but schema maintenance: applying a saved definition to an existing table makes that table match the definition, and anything on the table but not in the definition is dropped along with its data. That is why every schema change is proven against a copy of the company file and the definitions are version-controlled.
Can custom tables be read through the Accredo API?
Yes, provided the table was built for it. A custom table used through the web service needs exactly one field that uniquely identifies each row, indexed as both unique and primary, and its name must stay within plain letters, digits and underscores — punctuation in the name breaks the metadata the service publishes. Both are trivial at definition time and unpleasant to retrofit once the table holds data and other things depend on it, so they are worth settling before the first row is entered.
Can a custom field in Accredo be made mandatory?
Not by the definition itself. A field added to one of the product’s own records cannot be marked as required, cannot auto-number, and an index added over it cannot enforce that a value appears only once. Where the business rule is genuinely that something must be filled in, it is enforced by a script running when the record is saved, which also lets the rule be conditional — required for one type of customer and not another, which a tick box could not express anyway.