Platform Overview

What ActiveManage Can Do

ActiveManage is a platform for building and running business applications — the kind an organisation depends on daily, with real data, real users and real access rules.

Where to find it

Architect Panel → Data:

• Datastores — where you describe the shape of your data

Architect Panel → Configuration:

• Platform Modules — the capabilities enabled on this instance

What you describe, and what you get

You describe your data once as a datastore. From that single description the platform derives the database table, the create, edit and view forms, browse views, the search index, the REST API, the audit trail and the permission surface.

The practical consequence is the one that matters: adding a field is one change, not eight. In a conventionally built application the same addition touches the schema, the migration, two forms, a list view, an API contract, a test and the documentation — and the places it fails to reach are where bugs live.

The kinds of application it suits

• Case and record management — anything where a thing arrives, is worked on by several people, and has to be evidenced afterwards.
• Line-of-business operations — bookings, assets, projects, stock, finance.
• Regulated work — where the audit trail, retention and access controls are as much of the requirement as the features.
• Customer-facing portals — where the same records are visible externally under tighter rules.
• Multi-tenant products — one installation serving many isolated organisations.

What comes as standard

Authentication and single sign-on, two-factor, permissions to row and field level, audit logging with tamper evidence, retention and disposal, search, document generation, e-mail and SMS, scheduled tasks, an API, and reporting. None of these are projects; they are settings.

That is the actual argument for a platform. Any competent team can build a booking system; the twelve months afterwards are spent building everything in that list around it.

What it is not

Being straightforward about this saves everybody time. It is not a website builder, not a general programming environment, and not the right tool for something whose value is a novel algorithm or an unusual interface. It is for applications whose shape is records, rules, people and process — which is most business software, but not all of it.

You are not locked out of code

Where a screen genuinely needs to be bespoke, it can be. The point is that the other ninety screens do not, so the effort goes where it is actually warranted.

Worked example

A housing association replaces three systems and a set of spreadsheets. Repairs, tenancies and compliance inspections become datastores; the contractor portal is the same records under different permissions; the regulator's evidence request is answered from the audit log. Nothing in that list required custom code, and the parts that did — a scheduling screen the team wanted laid out a particular way — were built as exceptions rather than as the norm.

Recommendations

• Model your data before designing screens. Everything derives from it.
• Check what is already standard before building it.
• Reach for custom code as an exception, not as the starting point.
• Be honest about fit — the platform is excellent for record-shaped problems and mediocre for others.

How the Pieces Fit Together

The platform is easier to learn if you carry a model of how its parts relate. Nearly every question you will have belongs to one of five layers.

Where to find it

Architect Panel → Data:

• Datastores — the foundation everything else derives from

Architect Panel → Layout & Pages:

• Pages — the interface layer

Architect Panel → Security:

• Permissions — named permissions
• Record Access Roles — row-level access

Architect Panel → Automation:

• Journeys — process
• Tasks — scheduled work

1. Data

Datastores describe what you hold. Fields have types, validation and defaults; datastores have relationships, numbering, retention and audit settings.

This layer is the foundation in a literal sense — the four layers above it are derived from it, so a mistake here propagates and a change here is felt everywhere. It is worth more of your attention than anything else.

2. Interface

Forms, browse views, pages and dashboards. Most of this is generated from the data layer; you adjust rather than construct.

When a field is not appearing where you expect, the question is almost always a data-layer or access-layer one rather than an interface one.

3. Access

Who can see and do what. Security groups collect users; permissions are granted to groups at datastore and field level; record access roles control which rows a person can reach.

Access is grant-based: something not granted is not permitted. There is no deny list to reason about, which makes "why can this person see this?" a question with a traceable answer.

4. Automation

Journeys move records through a process. Tasks run work on a schedule. Rules react to changes.

This layer is where a system stops being a database with forms and starts being an application.

5. Operations

Logs, audit, backups, retention, monitoring, deployment. Largely automatic, and mostly noticed when something has gone wrong — which is the argument for looking at it when nothing has.

How to use the model

When something is not behaving, identify the layer before investigating:

• Wrong or missing value → data.
• Right value, not displayed → interface or access.
• Somebody cannot get in → access.
• Something did not happen → automation, then operations.
• Everything is slow → operations.

Most time lost to debugging is lost in the wrong layer.

Build in the same order

Data, then access, then interface, then automation. Building screens before the data is settled means rebuilding them; adding permissions after go-live means discovering who has been seeing what.

Worked example

A user reports a missing field on a form. Data layer: the field exists on the datastore. Access layer: their group has no field permission on it. The interface was never the problem, and the fix takes a minute once the layer is identified — where a search through page configuration could have taken an afternoon.

Recommendations

• Identify the layer before investigating.
• Build in order — data, access, interface, automation.
• Spend disproportionate effort on the data layer.
• Look at the operations layer when nothing is wrong.

Hosting and Deployment Models

The platform is not tied to one hosting shape. The same application runs on a single modest server or across a sharded multi-tenant estate, and the difference is configuration rather than code.

Where to find it

Architect Panel → Configuration:

• Site Settings — deployment target and tenant database mode
• Multitenancy — tenant configuration and isolation

Architect Panel → Integration & Connections:

• Database Hosts — the servers tenant databases are distributed across
• Deployments — pushing a version out

Single server

One PHP-capable web server and one MySQL or MariaDB database. Right for internal tools, small products and every development environment.

Do not over-engineer past this before you need to. A single well-specified server carries a surprising amount of load, and the operational simplicity is worth real money.

Multi-tenant, shared database

Every tenant's rows live in one database, separated by a tenant identifier carried on every row. Cheap to run, simple to back up, and the default.

The isolation is enforced in the platform rather than by the database, which is why the tenant column is present everywhere and why you should never bypass the platform's query layer in custom code.

Multi-tenant, separate databases

Each tenant gets its own database, with connections managed for you. Choose this where isolation is a requirement rather than a preference — a regulator asking how one client's data is separated from another's is much more easily answered by "different database" than by "a column".

It also makes per-tenant restore possible, which is the operational argument. Restoring one tenant from a shared database is an extraction exercise; from a separate database it is a restore.

Sharding

When one database server is not enough, tenant databases are distributed across several Database Hosts. Sharding works with either isolation mode.

This is a scaling answer, not a starting position. Introduce it when a single host is genuinely the constraint, and not in anticipation.

The five deployment engines

• AWS Beanstalk — for autoscaling production estates.
• SFTP and FTP/FTPS — for conventional hosting.
• Network Drive and Local Folder — for on-premises and development.

Deployment pushes a version of the application out through the chosen engine. Database changes are a separate, deliberate exercise — they are not applied automatically as part of a deployment, and they are not gated by an automated test run. Plan schema work as its own step with its own rollback.

Choose isolation before go-live

Moving from shared to separate databases after tenants are live is a migration, not a setting change. Decide at the start, and lean towards separate if there is any prospect of a client asking the isolation question.

Worked example

A product launches on a single server with shared tenancy. At around forty tenants, two enterprise customers ask for their data to be separately held, so those two are moved to separate databases while the rest stay shared. A year later a second database host is added and the largest tenants are distributed across both. Nothing about the application changed at any point.

Recommendations

• Start on a single server.
• Decide the isolation mode before tenants exist.
• Shard when a host is the constraint, not before.
• Treat schema changes as their own deployment step with a rollback.