Account Lists are lists created and edited at the Account Layer using the same list editor you already use in workspaces. Once an Account List exists, an Org Controller can pull it into any workspace in the same Sitemate Start account — keeping reference data such as employees, project codes, equipment registries or sub-contractors consistent across multiple workspaces.
Definition
An Account List is a list stored at the Account Layer rather than inside a specific workspace. It is edited using the same list editor available in workspaces — add rows, add and configure columns, edit values, apply styles and colours, reorder rows, do bulk operations, and attach files to cells.
Account Lists can be pulled into a workspace by an Org Controller from that workspace's list page. The pulled copy carries a Sitemate Start badge so workspace users can see at a glance that it tracks an account-level source. Updates flow automatically from the Account Layer to every workspace that has pulled the list.
What it's used for
Account Lists are used to:
Maintain a single master reference list that needs to be the same across multiple workspaces (for example, a corporate employee list, a project codes register, or an approved sub-contractor list).
Push updates centrally. When the Account Admin updates an Account List, the update flows down to every workspace that has pulled it.
Enforce consistency. Pulled lists are read-only at the workspace level — workspace users cannot create new items, edit existing ones, or change columns. All changes happen at the Account Layer.
When to use it
Use an Account List when:
The same reference data is used in more than one Dashpivot workspace.
Consistency matters for reporting or analytics (for example, every workspace needs to use the same employee names so attendance can be aggregated).
You want updates to a list to roll out automatically across workspaces.
You want to prevent workspace users from modifying the list.
If you need workspace users to be able to add their own items, the existing workspace-level List Library is the right place — Account Lists are intentionally read-only in workspaces.
How Account Lists compare to workspace lists
Capability | Account List | Workspace List |
Edit location | Account Layer detail page | Inside the workspace |
Editor | Same list editor used in workspaces | Same list editor |
Editable by | Account Admin / superuser (at the Account Layer only) | Org Controller / Project Controller (in the workspace) |
Available in | Multiple workspaces (via Pull from account layer) | One workspace |
Workspace badge | Sitemate Start badge on pulled copies | None |
Workspace home view | Read-only | Editable |
Project folder view | Read-only + Add Item picker (restricted to parent list items) | Editable + Add Item creates new items |
Updates propagate | Yes — to every workspace that has pulled it | N/A |
Date-expiry notifications | Configured per workspace after pulling | Configured per workspace |
Locking behaviour — Account Templates vs Account Lists
Both Account Templates and Account Lists are read-only at the workspace level. The full edit must happen at the Account Layer.
Action | Account Templates | Account Lists |
Edit structure at workspace level | Not allowed | Not allowed (column structure locked) |
Add new items / rows at workspace home level | N/A | Not allowed (Add Item disabled) |
Add new items / rows at project folder level | N/A | Not allowed — Add Item is a picker restricted to existing items in the parent Account List |
Edit existing items at workspace level | N/A | Not allowed |
Remove items at workspace level | N/A | Not allowed |
Updates propagate from Account Layer | Yes | Yes |
The one workspace-side capability that differs from a fully read-only model is the project folder Add Item picker — workspace users can choose which items from the parent Account List appear in a specific project, but they cannot create new items at any workspace level.
A note on date-expiry notifications
Account Lists can have a date-expiry column, but the notification bell is hidden on the account-level list in V1. Date-expiry notifications are configured per workspace by the workspace admin after the list has been pulled in. This means each workspace can have its own notification recipients, and the workspace starts with no one subscribed until someone is configured.