Not every organizing principle deserves its own type or property. Sometimes users just want to mark a batch of records as urgent for the next two weeks, or tag everything related to a specific campaign, or note that a set of items needs review before it can move forward. Sometimes a tenant just wants to drop a handful of files into a folder labeled "Policies" without negotiating a formal document taxonomy. Sometimes an implementer wants to group their fifty-seven automations into a few folders so the list doesn't look like a flat dumping ground. These are all legitimate organizing impulses that don't justify schema changes. Tags and folders give users the informal structure they need without forcing every grouping decision into the data model.
Tags as lightweight labels are the simplest organizing tool. A user types a tag name into a tag field on a record — creating the tag on the fly if it doesn't exist — and the record is labeled. The same tag can be applied to any number of records; the same record can carry any number of tags. No implementer setup is required beyond enabling tags on the relevant type; users can do the labeling themselves in whatever way makes sense for their work. For the "group these things together temporarily" and "mark this set for a specific reason" patterns, tags are the right tool, available on demand.
Color-coded tags make tag-based organization visually scannable in list and table views. Each tag gets a color — either chosen explicitly or assigned automatically — and a tagged record displays its tags as colored chips. A table view with tags visible becomes legible at a glance: the urgent tag is red, the Q2 campaign tag is blue, the review tag is yellow, and the user can spot the pattern in the data without reading every row. For views that hold hundreds of records, that visual encoding is the difference between a usable view and a wall of text.
Filter by tag makes tags actionable in every view. Any view can filter to show only records carrying a specific tag, or any of several tags, or records that don't carry a particular tag. The filter is part of the query builder, consistent with every other filter dimension, which means tag filters compose naturally with date filters, status filters, and whatever else the query is doing. A saved query like "all open tickets tagged urgent" is exactly the kind of ad-hoc grouping that tags are designed to support and that tag filters make operational.
Folders in the file repository give files a hierarchical structure without requiring each file to be tagged or typed. Create a folder, drop files into it, create subfolders for finer-grained organization — the familiar model of a file system, applied to the platform's file repository. The folder structure becomes a navigation tool: breadcrumbs show where the user is; drag-and-drop moves files and subfolders around; bulk operations apply within folder scopes. For the large volumes of documents that many tenants accumulate — policies, templates, archives, shared assets — folders are the organizing structure users already know how to work with.
Folders for implementation artifacts scale with the tenant's complexity. A tenant that's grown to hundreds of queries, dozens of views, and a substantial automation library benefits from the same folder metaphor applied to those artifacts. Queries can be organized by business area — Sales, Finance, Operations — with subfolders for finer topics. Views can be grouped per type or per department. Automations can live in folders that reflect the workflows they support. Without this structure, a large implementation's list of artifacts becomes an undifferentiated dumping ground; with it, the list becomes a navigable library.
Drag-and-drop into folders is the organizing gesture that makes the folder model feel natural. Files can be dragged onto folder icons in the tree; queries and views can be dropped into folders from the management interface; automations can be reorganized the same way. The interaction is what users already do on their desktop, which means there's nothing to learn. The files or artifacts arrive in their new location; the folder's content list reflects the move; the rest of the platform's references to those items continue to work regardless of where they live in the folder tree.
Move vs. link handles the cases where an item belongs in more than one place. A policy document might logically belong in both the HR folder and the Compliance folder; a shared query might serve multiple departments. Rather than forcing a single canonical location, folders can contain references in addition to exclusive placements — an item can have one primary location and be linked from others. Changes to the item are reflected wherever it's referenced; the item is only removed when explicitly deleted. For real-world organizing needs where the neat-tree model doesn't quite fit, the link semantic keeps the folder structure useful without distorting the data.
Tag permissions handle the spectrum between "controlled vocabulary" and "free-for-all." Some tenants want tags to be a controlled vocabulary — curated by admins, applied by users from a defined list, kept clean by design. Other tenants want tags to be free-form — created on the fly, applied by any user, organic in their vocabulary. Both modes are supported: a role's permissions include whether it can create new tags versus only use existing ones, which means tag discipline is a per-tenant policy decision rather than a platform opinion. Organizations that benefit from free-form tagging get it; organizations that need discipline get that instead.
Renaming and merging keep tags from accumulating noise over time. A tag typo — rurgent instead of urgent — doesn't have to mean the mistagged records are stranded forever. Tags can be renamed, and the rename applies to every record carrying the tag. Two tags that should be one — review and to review having been created separately by different users — can be merged, with all records previously carrying either tag now carrying the merged result. For the tag hygiene that inevitably becomes necessary as a tenant's tag vocabulary grows, these operations are how admins keep the vocabulary usable.
Tag colors and icons round out the customization. Beyond the automatic color assignment, tenants can customize tag appearance for vocabularies that benefit from intentional design — a status-tracking tag set where the colors carry meaning (green for complete, yellow for in-progress, red for blocked), for example. That's a small thing that adds up to users being able to understand their data at a glance, rather than having to read every label.
For end users who want to organize their work without waiting on an implementer, for tenants whose organizing needs don't fit into rigid schemas, and for implementations that have grown to the point where a flat list of artifacts is unworkable, tags and folders are the lightweight organizing tools that fit. For the adjacent topics, the file repository article covers the folder model for files in depth, the queries article covers how tag filters compose with other query conditions, the views article covers how tagged records appear in different viewers, and the automations article covers how folder-organized automation libraries work at scale. Organize without rearchitecting — that's the value these two small features provide, and why they earn their place alongside the heavier structural ones.