Admin Grids are a system-wide administration feature in Cora PPM that allows administrators to define and manage custom, configurable lookup tables — structured data collections that other parts of the application can reference. Think of them as custom reference-data tables that go beyond simple dropdown lists: each Admin Grid is a named table with a user-defined identifier, description, and one or more typed fields (columns), plus a set of data rows (items) holding values for those fields.
What problems do they solve?
Cora PPM often needs structured reference data that is more complex than a single-column dropdown — for example, a lookup that has a code, a label, a date, a linked user, and a linked cost centre all in the same row. Admin Grids let administrators build those multi-column lookups without requiring code changes.
Two flavours of Admin Grid
Flavour | Description |
|---|---|
Standard | A general-purpose, configurable multi-column data table. The administrator defines fields and populates rows of data. |
Hierarchy (feature-flag gated) | A specialised grid where each "field" is actually a hierarchy level (e.g., Division → Department → Team). This type underpins the Project Role Hierarchy feature, which lets administrators assign users or roles to specific hierarchy levels on a per-project basis. |
What can a field in an Admin Grid hold?
When configuring the columns of an Admin Grid, each field has a source type chosen from:
Project Type – references the system's project-type list
Project Status – references the system's project-status list
Dropdowns – references a system-wide dropdown list (custom fields of type "All")
Smart Form Field – references a smart-form/custom-details field (area = Project Custom Details)
Global Site – references global site values
Open Text – a free-text entry field
User Custom Attributes – references user-level custom data attributes
Mandatory validation can be enforced on any field. Fields can be reordered by drag-and-drop. An Admin Grid can contain up to 15 fields in the standard configuration path.
The data lifecycle
Define the grid – give it a numeric ID, description, optional comment, type, and archived status.
Define its fields/columns – add each column specifying its source type, label, and whether it is mandatory.
Populate data rows – click through to the field values screen to add rows, each row providing values for every column.
Connect to projects – for Hierarchy-type grids, the grid is linked system-wide and individual projects then bind specific users/roles to each hierarchy level via the Project Role Hierarchy page.
Archiving and protection
A grid cannot be archived while it is in use (i.e., it has one or more fields defined). Similarly, a grid's type cannot be changed once it has been put into use. These safeguards prevent orphaned configuration data.
Full audit trail
Every creation, update, archival change, and field-detail change is recorded in the system's configuration history log
API exposure
Admin Grids are also fully exposed through the REST Web API, allowing external systems to read grid definitions, fields, and field values, and to create or update them programmatically. Access is restricted to administrators.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article