Core Tables
Contact data within Adestra is stored in core tables. Core tables contain one record for each of your contacts. Each record will have email address and an ID assigned by Adestra and can contain a number of other fields specific to your mailing list data.
On this page:
Overview
Core tables are completely separate from one another, so we would therefore recommend using one core table per data source. Most accounts have one primary core table, we would not recommend having more than this as your account may become complicated to manage. Admin users or data admin users can manage core tables; non-admin users can see and browse core tables, and manage any associated lists, but cannot create or edit them.
You can access core tables in the Data section via the header at the top of the screen and then using the Core Tables tab.
This page displays the core table list, including each table's name and contact count.
You can select an existing core table by clicking on its name, which will take you to the core table overview.
The core table overview displays details of the core table, including its current contact count.
Note: If you have recently imported a very small number of contacts, the contact count may take time to update to the new total.
The fields that the table contains are displayed in the field list.
Handling Duplicate Records
You can configure how duplicate records are handled during import when creating or editing a core table. The dedupe method and field is displayed here.
Fields
Each field is assigned a type, which can be used to identify the field's contents regardless of its name. This can be useful in situations when field names are not suitably descriptive. The field type will default to 'Text' but you can change this using the drop-down box. The field type you select doesn't affect your data, though all fields are limited to 255 characters. The only exception is the 'Large Text' option which can be used in situations when you need to store more than 255 characters.
We would recommend that the fields in your core table be relevant to all of your records, for example first name and surname etc. For additional fields that are only relevant to portions of your data, for example survey answers, you can use Data Tables.
Protected Fields
Fields may be marked as "protected". This prevents non-admin users from accessing the contents of those fields in bulk. That is, the field will be visible to non-admin users if they are viewing a single contact, but will be hidden if they are browsing a number of contacts or attempting to download a CSV. It will also be hidden from link activity and link label reports. This is intended to help prevent data leaks by making it much harder to access particular fields in quantity, while still allowing users to work with contact data effectively.
Lists
You can see all of the lists that are assigned to the core table using the 'Lists' link.
For help with lists refer to the Lists and Importing topics.
Browse
The Browse tab of a core table lets you view the contact data within that table. Whenever you browse data in Adestra you will be working with the data viewer, which allows you to view and modify sets of contacts and edit individual contacts. For help using the data viewer and managing contacts, see the Data Viewer and Contact Profile topics.
Import Log
The import log page shows the data files that have been imported into the core table. You can click on the filename of an individual import to see more detailed information for that import.
This page gives a breakdown of the import, along with download links for bad and duplicate records.
In the lower part of the page, the import map shows how the fields were mapped to the core table on import.
For help with importing, see the Importing topic.
Permissions
The Permissions tab appears if the core table is flagged as private, meaning it is only available in certain workspaces.
Note: This tab is available to data admin users.
This page displays the workspaces available to your user and shows whether or not the core table is visible in each workspace.
The permissions can be altered for each workspace using the drop-down boxes on the right-hand side.
To make the core table visible in a workspace select Grant and to make it invisible to a workspace select 'Revoke'. If you make any changes, remember to click the 'Update Permissions' button beneath the table on the left-hand side and the 'Access' column with reflect the visibility status.
Settings
The settings tab is only available for admin or data admin users who are responsible for editing core tables.
Managing Core Tables
Although accounts typically only have a single core table, it may be the case that you require more than one core table. For example, it could be that you have separate core tables for separate workspaces to differentiate your data, or your account may contain a training core table for use within a training workspace.
If you are an admin or account admin user, the Create Core Table button will be available above the core table list.
You can edit an existing core table by clicking on its name.
Note: Once a core table has been created it cannot be deleted, so it is important to make sure it is set up correctly. If you need help at any stage, contact your account manager or Adestra Customer Support (adestra-support@uplandsoftware.com).
Creating Core Tables
Table name
The table name is used throughout the system to refer to your table.
Description
The description is an optional field that can contain any additional details or information about the table you like.
Owner
The owner of the core table will default to your user but you can change this using the 'Select User' button.
Permissions
These options determine where in the account the table can be viewed. You can restrict the table to only be available in the current workspace, and any workspaces defined in the Permissions tab, or you can make it available within all workspaces.
Duplicate record handling
Configuring the duplicate record handling options against the core table allows you to define how duplicate records should be handled across the entire table, simplifying the import process.
| Duplicate Record Handling Option | What it Does |
|---|---|
| Overwrite the duplicate records |
This method will add any new contacts to the core table and overwrite any existing data if a duplicate is found. If your CSV file is more up-to-date than the existing data it will ensure that the data in your core table is the most recent. For example, if you had a CSV file containing the address changes of your contacts, overwriting duplicate records on import would mean that the new addresses of any contacts matched would replace the old address data in the core table. |
| Keep the data already in your table |
This method will add any new contacts to the core table, and ignore any duplicate records. For example, the record would not be imported if the dedupe field were 'email' and both the core table and the CSV file contained the address example@adestra-demo.com. Although this will ignore duplicates in the core table, the contacts will still be added to the list that the CSV is being imported into if they are not on it already. Keeping the data already in your core table will reduce the time taken to import, however this data may not be the most up-to-date. |
| Do not check for duplicates (not recommended) |
This method will import all records from the CSV, regardless of the existing data in the core table. This means that records containing matching or conflicting data will exist simultaneously on the core table, which can cause it to become large and unmanageable. |
|
User defined
|
Selecting user defined will allow users to decide per import how duplicates are handled, however this will only provide the option to overwrite duplicates or keep the existing data. The option to not check for duplicates will only be displayed for users if your account has been configured that way. |
Table Fields
All records within a core table must contain at least an email address, and this field comes predefined when creating a new core table. You can add your own fields, such as name or address, clicking the 'Add New Field' button, which will create a new field underneath any existing fields for you to define. We would not recommend more than 20 fields in your core table, as more than this can be difficult to manage.
Note: The order in which the fields are added here is the order they will appear in throughout the system, so make sure they are correct before saving.
Name
The field name will initially be blank for you to enter a name and it can be useful later, for example with data exports, if field names match CSV column headers.
Type
The field type will default to 'Text' but this can be changed using the drop-down box to select a different type.
Protected
You can also mark individual fields as protected. This option can be removed later if necessary.
Dedupe Field
You have the option to select which field will be used to dedupe by, for example, email address or a unique identifier such as 'contact_id'. This is the field that will be used to compare the CSV file against the database. If no field is selected, by default the system will dedupe by email.
Clicking 'Save' will create the core table.
Editing a Core Table
You can edit a core table using the 'Settings' page, which displays a form where you can change the basic details of a core table, including the name, description and owner.
You are able to change the duplicate record handling method and the dedupe field, and any changes made will be applicable to future imports.
There is also the option to add, edit or remove fields, though if you wish to make any significant changes, contact your Account Manager before doing so—as any changes you make can affect campaigns that use lists associated with the core table.
Note: The Core Table fields that are used on an Export cannot be removed.
You cannot import more data directly to the Core Table; this must be done through the lists interface.
FAQ
The contact count does not show the most up-to-date number of contacts, why is this?
Why is the table count not accurate?
The contact count on a core table may take some time to update to reflect the correct count, particularly if you have a very large table. Therefore, we use an estimated number of rows provided by our database for this number. It's usually a good representative figure, but is likely to be slightly incorrect for accounts that have regular imports or make frequent updates to their contact records.
For most users this is sufficient for their use case, as core tables aren't used directly when sending email campaigns. Instead, campaigns are sent using Lists, and list counts should always be accurate.
Can I delete core tables?
No, it is not possible to delete core tables. If you need help organising your account, contact your account manager or Adestra Customer Support (adestra-support@uplandsoftware.com).
How many core tables can I create?
There is no limit to the number of core tables you can create. However, we recommend that the only time you should have more than one core table is if you were working with two different, completely unrelated sources of data.
I received an error message that says "This table's schema cannot be currently modified, there may be other locks preventing schema changes". What should I do?
This message means your core table is being used by the platform for at least one other long-running process, such as launch, export, or filtering, and it can't be modified while it's running one of those processes. We put these guard rails on core table modification to prevent unexpected issues with the tables. If you see this error message consistently, contact Product Support.
How many records can a core table contain?
There is no limit to the number of records a core table can contain.
How many fields should a core table contain?
We recommend no more than 20 fields in your core table, as more than this can be difficult to manage.
Is there a character limit to the field contents?
For all intents and purposes, yes. All fields are limited to 255 characters, except for 'Large Text' fields, which have a limit of 9,999 characters.
Note: Technically speaking, characters are stored as UTF8 byte strings, and character limits are actually byte limits, so the actual number of characters that may be stored in a field depends on the UTF8 representation of the data.
Can I rearrange the order of the fields in the core table?
No, the core table fields cannot be rearranged. Fields appear in the order in which they were added.
Can I add more than one email address per record?
No, Adestra expects a single email address for each contact.
Can I remove records from a core table?
No, you cannot remove records from core tables.
However, you can remove contacts from lists, which are used when sending your campaigns. For help removing contacts from lists, refer to the Lists topic.
Can I remove duplicate records from core tables?
No, duplicate records cannot be removed from core tables, so it is important that your account is set up avoid including duplicate records when it's first created.
For help organising your account, contact your account manager or see other options in the Support topic.
Can I change the workspace a core table is assigned to?
If a core table is available only in a specific workspace, you have the option to change it to be available in all workspaces.
Note: Once you have changed this to all workspaces, this cannot be reversed.