Data Update Preparation
Setup Guide — Getting Tables Ready to Edit in Data Update
Module: Data Update › Config | Last updated: August 2026
Contents
- Overview
- Where the Tables Come From
- Key Concept: The Three Table States
- Finding Your Way Around
- Refreshing Tables From Your Sources
- Onboarding a Discoverable Table
- Table Settings and Turning On Editing
- Configuring Columns
- The Audit Mirror
- Quick Reference
1. Overview
Data Update lets your team edit business data directly inside OnCoor — fixing a value, filling a gap, or correcting a batch of rows — with every change recorded in an audit trail. But before anyone can edit a table, that table has to be prepared. That's what this page, Data Update Preparation, is for.
Preparation is admin-and-steward work done once per table. It answers four questions: Which tables do we want to work with? Where should edits be written? Which columns can people change, and how? And how do we record the history of those changes? Get those right here, and the day-to-day editing that happens elsewhere in Data Update is safe and simple.
What you can do here
- See every table from your connected source systems in one place, grouped by how ready it is.
- Onboard a new table so OnCoor can manage and edit it.
- Switch editing on or off for a table.
- Choose which columns are shown and editable, and turn free-text fields into governed pick lists.
- Set up the audit mirror that records the history of every edit.
WHERE TO FIND IT — This page lives in the portal's left-hand navigation under Data Update → Config → Data Update Preparation. (The exact position of the Data Update menu is set by your administrator through Menu Design.)
2. Where the Tables Come From
You don't add tables to this page by hand — OnCoor gathers them automatically from your connected Sources. A Source is a connection to one of your systems (a SQL Server or Oracle database, for example) that has been set up in OnCoor as an external source. These are the same sources used elsewhere in OnCoor to pull data in.
For each external source, OnCoor scans the system to learn what tables it holds, and remembers that list. Everything on this page is then built from two things:
- Tables that exist on your sources, found by scanning. A source table that OnCoor hasn't taken in yet appears as Discoverable.
- Tables already in OnCoor's catalog — ones taken in previously, either by onboarding them here or through other flows such as Quick Import. Depending on whether editing is switched on, these appear as Enabled or Available.
So a table's journey looks like this:
A table lives on a source system → OnCoor scans the source and lists it as Discoverable → you onboard it, which creates a catalog entry → it becomes Available, and once editing is on, Enabled.
Each row on the page carries small chips telling you exactly where it came from: the source it belongs to, and — once it's in OnCoor — the data server where its data (and therefore its edits) live.
ONLY EXTERNAL SOURCES ARE SCANNED — This page draws only from sources marked as external connections in OnCoor, and only SQL Server and Oracle sources can be scanned for Discoverable tables. If a table you expect isn't listed, its source may not be set up as an external source, may be an unsupported type, or may simply need a refresh — see Refreshing Tables From Your Sources. Tables from unsupported source types can still be brought in with the Bring data in mode.
3. Key Concept: The Three Table States
Every table on this page sits in one of three states. The state tells you what, if anything, you need to do before the table can be edited. They appear as coloured labels on the table list and as filter chips at the top of the rail.
| State | What it means | What you do about it |
|---|---|---|
| Enabled | The table is fully set up and already appears in the Data Update edit grid. | Nothing — it's ready. Open it to fine-tune its columns or audit table. |
| Available | OnCoor already knows about the table (it's in the catalog), but editing is switched off. | Flip one toggle to turn editing on — see Table Settings. |
| Discoverable | A live table on one of your source systems that OnCoor hasn't taken in yet. | Onboard it — see Onboarding a Discoverable Table. |
Rule of thumb: Discoverable means "found but not yet in OnCoor", Available means "in OnCoor but editing is off", and Enabled means "ready to edit". Onboarding moves a table from Discoverable into OnCoor; enabling moves it the rest of the way.
WHY THREE STATES — Not every source table should be editable, and some aren't in OnCoor at all yet. Splitting them this way means you only ever see the one decision that matters for each table, instead of a single long list where everything looks the same.
4. Finding Your Way Around
The page has two parts:
- The main area shows your Enabled and Available tables as cards when nothing is selected, so you can jump straight to the one you want. Selecting a table fills this area with its settings (or, for a Discoverable table, the onboarding wizard).
- The table rail on the right lists every table grouped by state, with filter chips, a source filter, and a search box. This is where you pick a table to work on.
The rail gives you three ways to narrow a long list:
| Tool | What it does |
|---|---|
| State chips (Enabled / Available / Discoverable) | Show or hide a whole group. Each chip also shows how many tables match your current search. |
| Source chips | When more than one source feeds the list, filter to a single source system. |
| Find a table | Type part of a table name and press Enter (or click Search) to filter the list. The ✕ clears it. |
NOTE — The search applies when you press Enter or click Search, not on every keystroke. A small hint appears until you apply it, so you always know whether what you typed is in effect.
5. Refreshing Tables From Your Sources
The list of Discoverable tables comes from OnCoor scanning your source systems. If you've just added a table on a source system, OnCoor won't see it until it scans again. That's what Refresh tables does — the circular arrow button at the top of the rail.
Steps
- Click the Refresh tables icon at the top of the rail.
- Wait while OnCoor re-scans every connected source. This can take a moment, as it queries each source system live.
- A message tells you how many sources refreshed successfully, and names any that had a problem.
The first time you open the page and the list is empty, OnCoor runs this refresh for you automatically, so you're not left staring at a blank page.
SUPPORTED SOURCES — Data Update can scan SQL Server and Oracle sources. Other source types (such as File, Redshift, or HANA) are skipped during a refresh — this is expected and isn't an error. Tables from those systems can still be brought in using the Bring data in mode described below.
6. Onboarding a Discoverable Table
Onboarding is how you take a Discoverable source table and make it into something OnCoor can manage and edit. Select a Discoverable table from the rail and the main area shows the Onboard wizard.
The wizard asks for two things, both pre-filled with sensible defaults you can change:
| Field | What it's for |
|---|---|
| Conform Data Name | The name this table will have inside OnCoor. Must be unique. Defaults to the source table's name. |
| Audit Table Name | The name of the companion table that will store the history of every edit. Defaults to the table name followed by __a (for example, MARA__a). Leave it blank to accept that default. |
Then you choose how to onboard it. There are two modes, and the right choice depends on one question: where should edits actually be written — back to the original source system, or to a copy inside OnCoor?
6.1 Update in source
Edits are written straight back to the source database. OnCoor doesn't copy the data; it simply mirrors the connection and models the table so that the column settings and the audit trail still work. No data pipeline is built, so this is the lighter-weight option and the quickest to set up.
Choose this when the source system is the true home of the data and you want your corrections to land there directly.
AVAILABLE FOR SQL SERVER AND ORACLE ONLY — Because edits go back to the live source, this mode works only for SQL Server and Oracle sources. For any other source type the option is shown but disabled, with a note explaining why — use Bring data in instead.
6.2 Bring data in
OnCoor runs its full Quick Import process to copy the table into OnCoor's own cleansing area. Edits and the audit trail then live alongside the rest of your OnCoor data, and the original source is left untouched. This takes longer because it runs several steps (Intake → Mapping → Generate → Run), which you'll see tick off in the wizard.
Choose this when you'd rather work on a copy inside OnCoor, or when the source isn't a SQL Server or Oracle system.
| Update in source | Bring data in | |
|---|---|---|
| Where edits land | The original source database | A copy inside OnCoor |
| Copies the data? | No | Yes |
| Speed to set up | Fast | Slower (runs the full import) |
| Works with | SQL Server, Oracle | Any source type |
6.3 What Happens to Editing After Onboarding
Onboarding a table creates its entry in OnCoor's catalog — but a table only appears in the Data Update edit grid when its Editable toggle is on (this is the master switch covered in Table Settings). The good news is that onboarding turns it on for you, so you don't have to do it as a separate step:
- After Update in source, the table is created with Editable already switched on.
- After Bring data in, OnCoor switches Editable on automatically once the import finishes.
Either way the table lands in the Enabled group, and OnCoor selects it for you so you can carry straight on to its column settings. If you ever need to take a table out of the edit grid later — without removing it from OnCoor — switch its Editable toggle off in Table settings; that moves it back to Available. Turning the toggle on again brings it back to Enabled.
ONBOARDING vs THE EDITABLE TOGGLE — Onboarding is a one-time step that brings a Discoverable table into OnCoor. The Editable toggle is the everyday switch that decides whether a table already in OnCoor shows up for editing. Onboarding simply sets that switch on for you at the end; from then on, the toggle is how you turn editing on or off.
7. Table Settings and Turning On Editing
When you select an Enabled or Available table, the Table settings card appears at the top of the main area with three fields:
| Setting | What it means |
|---|---|
| Conform Data Name | The table's name inside OnCoor. Shown here for reference but read-only — because lookups and the audit trail rely on this name, renaming is done on the Conform Data page rather than here. |
| Editable | The master switch. When on, the table appears in the Data Update edit grid so your team can edit it. When off, it's hidden. |
| Audit Table Name | The name of the companion audit table. Leave it blank to use the default <table>__a. |
Use Save settings to apply changes, or Reset to discard them. The buttons stay disabled until you've actually changed something.
To turn editing on for an Available table: select it, switch Editable on, and click Save settings. The table moves into the Enabled group and its column grid appears.
WHAT UNLOCKS WHEN YOU ENABLE — Column-level settings and the audit mirror only become available once a table is Enabled. That's deliberate: for an Available table the one decision that matters is whether to switch it on, so the page keeps everything else out of the way until you do.
8. Configuring Columns
For an Enabled table, the column grid lists every column. The left-hand columns are for reference only and describe each column — Seq (position), Column Name, Data Type (a plain-language description such as Varchar, Integer, Date), Len (maximum length), Nullable (whether it can be empty), and PK (a tick marks a primary-key column that uniquely identifies each row).
To change the settings on the right, click Edit Configuration. A "View only" / "Editing" badge shows which mode you're in.
8.1 Displayed and Editable
| Setting | What it controls |
|---|---|
| Displayed | Whether the column appears on the Data Update edit grid at all. Columns that aren't displayed are hidden from the people editing the data. |
| Editable | Whether the value can be changed. A displayed-but-not-editable column is shown for context only. |
EDITABLE IMPLIES DISPLAYED — Marking a column Editable automatically marks it Displayed too, since there's no point editing a column you can't see. Turning Displayed off clears that column's Editable setting (and its selection type and lookups).
8.2 Selection Type: Pick List or Free Text
Every column you make Editable needs a Selection Type, which decides how people enter a value:
| Selection Type | How editing works |
|---|---|
| Free text | People type the value in directly. Best for open-ended fields like descriptions or notes. |
| Pick list | People choose from a fixed list of approved values. Best for fields that should only ever hold one of a known set of values — a status, a category, a unit of measure. |
A SELECTION TYPE IS REQUIRED — You can't save an editable column without giving it a Selection Type. If you try, OnCoor tells you exactly which columns still need one.
8.3 Lookup Tables and Columns
When a column's Selection Type is Pick list, you tell OnCoor where the list of approved values comes from:
| Setting | What it means |
|---|---|
| Lookup Table | Which set of reference values to draw from. The options are your active Reference Configurations — the approved reference data already set up in OnCoor. |
| Lookup Column | Which column of that reference table holds the values people should choose from. |
When someone edits this column in the grid, the pick list they see is built from those values — so they can only choose from approved, governed data rather than typing something new.
BOTH ARE REQUIRED FOR A PICK LIST — A Pick list column needs both a Lookup Table and a Lookup Column. If either is missing when you save, OnCoor names the columns that still need them. And only active Reference Configurations appear in the Lookup Table list — if the reference data you want isn't there, create it in Reference Configurations first.
8.4 Columns You Can't Change
Some columns have their settings locked — their checkboxes are greyed out even in Editing mode — to protect the integrity of the data.
| Locked columns | Why they're locked |
|---|---|
| Primary-key columns (marked with a tick in PK) | These uniquely identify each row. They're always Displayed so people can tell rows apart, and never Editable — changing a key would break the link to the row's history. |
System audit columns (_updatedBy, _updatedDate) | OnCoor fills these in automatically to record who last changed a row and when. They're always displayed and never editable. |
8.5 Saving
Click Save. OnCoor checks your settings and, if anything's incomplete — an editable column with no selection type, or a pick list missing its lookup — tells you exactly what to fix. Click Cancel to back out and revert to the last saved state.
WHO USES THIS CONFIGURATION — What you set here is exactly what your data stewards see when they open the table in the Data Update edit grid: the columns you displayed, the ones you made editable, and the pick lists you wired up.
9. The Audit Mirror
When someone edits a value, OnCoor doesn't just overwrite the old value — it keeps a record of what the value used to be, who changed it, and when. That record lives in a companion table called the audit mirror, named after the table with __a on the end (so MARA → MARA__a). It sits on the same data server as the table's data.
Each time a row is edited, OnCoor writes a before-image into the mirror — a snapshot of the whole row as it looked before the change — alongside bookkeeping details recording the action, who did it, and when. Because the mirror carries a copy of the table's own columns, it has to match the shape of the table, which is why creating and occasionally re-verifying it matters.
For an Enabled table, the Audit table bar sits just above the column grid. It shows a status label (Created or Not created), the mirror's name, and three buttons that form a simple lifecycle:
| Button | What it does |
|---|---|
| Generate DDL | Shows the exact database commands that would build the mirror, in a window you can read and close. Read-only — it creates nothing. Useful for reviewing first, or for a database team that prefers to run the commands themselves. |
| Create | Builds the mirror on the data server over OnCoor's existing connection and registers it, so edits start being recorded. A one-time step — once the mirror exists, this button is switched off. Requires create permission. |
| Verify | Checks the mirror against the table and adds any missing columns (for example, after a new column is added to the table). Reports "up to date", "synced — N columns added", or "doesn't exist yet — click Create first". It only ever adds; it never removes or rewrites existing audit data. |
WHY IT MATTERS — Editing data is only safe when you can see what changed. The audit mirror is what makes the Data Update audit trail possible, so provisioning it is a required step before a table is truly ready for editing.
10. Quick Reference
A fast lookup for the most common actions.
| I want to… | Do this |
|---|---|
| See which tables are ready to edit | Look at the Enabled group |
| Make a newly-added source table appear | Click Refresh tables (the circular arrow at the top of the rail) |
| Find one table quickly | Type its name in Find a table and press Enter |
| Bring in a new table, editing it in the source system | Select the Discoverable table → Update in source → Onboard |
| Bring in a new table as a copy inside OnCoor | Select the Discoverable table → Bring data in → Onboard |
| Onboard a table from a non-SQL Server / non-Oracle source | Use Bring data in |
| Turn on editing for a table already in OnCoor | Table settings → Editable on → Save settings |
| Show a column without letting people change it | Set Displayed on, leave Editable off |
| Let people change a column by typing | Editable → Selection Type = Free text |
| Make people choose from approved values | Editable → Selection Type = Pick list → set Lookup Table + Lookup Column |
| Start recording a table's edit history | Audit table bar → Create |
| Add new columns to an existing audit mirror | Audit table bar → Verify |
Source: OnCoor Data Update product documentation, written for end users. For the latest screens and options, always refer to the in-app interface.