The nature of the task at hand—enabling users across organizations to play their parts in processes—demands a particular configuration of interfaces: ports for working, and dashboards for navigating to them. No more, no less.

Zooming in, a port is a single-entry form where the user performs their work on an item—say registering for an event or approving an expense. A port is optimized for the task at hand; it might offer a single large button for easy mobile use in the field, or sport many text fields designed for desktop completion. Common layout patterns such as a grid of fields can be configured rather than coded.

Multiple ports may exist for a collection, each presenting collection items in a way appropriate to the position that gets them. If a particular port is specified within an operation, the port extends the constraints on that operation, limiting say the fields that can be viewed or edited.

Zooming out, a role’s dashboard enables navigation to those ports where the role is fulfilled. Grouped by the organization’s various domains, the dashboard displays one domain workspace at a time.

A workspace is further organized into work stages based loosely on the Getting Things Done model. The stages are:

1. Awaiting (requires immediate action)
2. Current (action possible but not necessary)
3. Reference (no action required; helps with taking other actions)
4. Reports (no action required, often wider data spread than reference) 
5. Archival (no action possible; item no longer current)

Finally, a stage consists of an arrangement of consoles, each of which can be minimized or maximized like a GUI window. Consoles are the heart of the dashboard.

For various positions, a console may appear at various stages; one position’s ongoing work may be another’s reference.

A console presents a table of items to work on; the final column in each row offers one or more conduit links to various ports. In addition to standard columns displayed based on the content type, virtual columns can be added containing any fields and displayed using a custom template with a choice of coding languages.

Since every task across every department is handled this same way, there is only one mental model to learn, and institutional learning of the system can be rapid.

Development too is rapid. Leveraging Directus, every field in every collection contains rich metadata. With fields containing their own instructions—and ports enabling further per-field instructions to filter, display or render read-only—logic need not be coded on web pages; rather, most interfaces can be configured rather than developed. Such model-driven design makes creation of rich interfaces startlingly easy. 

Set per port, computed fields import values from anywhere in the system. Formula fields, set once at the collection level, contain not data but formulae that can be based on the values of any other fields, including other formula fields.

A port also has features such as field layouts (eg grid), enabling some fields to be displayed differently; virtual fields, useful for accepting user input that contributes to the value of computed fields; and embedded consoles, which display related collections. Embedded consoles can present as checklists, such as a roster of people with roles at the current body. Since an embedded console is a full-fledged console, each of its rows can point to further ports, determined as usual by the user’s available operations. Such child ports open like drawers.