Creating a new datastore is the single most common action when building an application on ActiveManage. The actual click-through is fast — fewer than 30 seconds for a basic table — but a few of the configuration choices deserve thought because they're hard to change later.
From the Architect Panel, open Datastores and click the green New Datastore button in the top-right corner. The configuration form opens with a stack of fields, grouped into a basic block, advanced toggles, and per-environment settings.
Core settings
The four fields you'll fill in for every datastore:
- Datastore Name — the internal name used in SQL queries, code, and API URLs. Must be lowercase, no spaces, no leading dot (that's reserved for system tables). Stick to plural nouns:
customers,orders,invoices,leaverequests. - Friendly Name — the human-readable name shown to admins and end users. Use proper case and natural plurals: "Customers", "Orders", "Invoices", "Leave Requests".
- Name of Rows — optional. Customises the singular label used on action buttons ("New Customer" instead of "New Record", "New Invoice" instead of "New Record"). If left blank, "Record" is used. Always worth filling in — "New Customer" reads much more naturally than "New Record".
- Database Host — almost always the primary database. Only change this if you've set up External Databases.
Advanced settings
The next block of toggles controls how the datastore behaves at scale and across tenants:
- Application Initialisation Mode — controls whether this datastore is created automatically on new tenant onboarding. Set to 2 to copy the structure but no data; set to 4 to copy both structure and seed data.
- Tenant Shared Data — when on, all tenants see the same rows (useful for reference data like a country list). When off (the default), each tenant has its own.
- Audit Mode — record every insert/update/delete on this datastore. Recommended for any datastore holding important business data; the overhead is small and the benefit is huge when investigating issues.
- Row-Level Security — enable to grant or revoke access on a per-row basis. See the Permissions section for how this works.
- Template Engine — enable if this datastore stores templated documents/emails that need to be evaluated server-side with merge tokens substituted.
- Default Page — the page to redirect to when a user navigates to this datastore as a friendly URL.
Three real-world configurations
Example 1: A simple Customers table
Name: customers. Friendly Name: "Customers". Name of Rows: "Customer". Database Host: primary. App Init Mode: 4. Tenant Shared: off. Audit Mode: on. Row-Level Security: off (most users can see all customers; row-level access by salesperson handled in browse views).
Example 2: A reference lookup table for Countries
Name: countries. Friendly Name: "Countries". Name of Rows: "Country". App Init Mode: 4 (seed list copied to every tenant). Tenant Shared: on (every tenant uses the same country list, so why have N copies). Audit Mode: off (countries don't change often, audit isn't useful).
Example 3: A multi-tenant Bookings table
Name: bookings. Friendly Name: "Bookings". Name of Rows: "Booking". App Init Mode: 2 (structure only, each tenant fills their own). Tenant Shared: off. Audit Mode: on. Row-Level Security: on (each customer sees only their own bookings via owner-based row rules).
Save, then add fields
Save the datastore. The underlying MySQL table is created automatically. You'll then see a Fields admin section appear — that's where you add columns to your new datastore. The next article walks through adding fields.
Warning: Renaming a datastore after launch is possible but risky — the underlying MySQL table is renamed, which means any external integrations referencing the old name will break. Get the name right at creation time and stick with it.