Quick Summary: There are TWO flag systems sharing no tables: people flags (
/api/v1/people-flags) tag a person; skill flags (/api/v1/skill-flags) tag a person at a career, section, skill-group or skill scope. A flag is the company-configured type; a flag assignment is a person carrying one.Attributes (both systems)
People flags
CRUD plusPOST /{id}/enable, POST /{id}/disable, POST /reorder, GET /{id}/dependencies, and a guarded DELETE /{id} (409 with the holder count; ?confirm=true proceeds). Assignments: GET /people-flags/{id}/people, and per person GET|POST|DELETE /people/{id}/people-flags — each assignment carries who assigned it and when.
Visibility exists only for people flags: one company-wide setting per audience at GET|PATCH /people-flags/visibility (administrators always see them — not configurable), and GET /people-flags/visibility/me resolves the answer for the acting identity.
Skill flags
The same lifecycle surface plusPATCH /{id}/trainer-designation. Dependencies and the guarded delete report counts per scope. Assignments live at /api/v1/skill-flag-assignments/{scope} where scope is careers, sections, skill-groups or skills — query with filters, POST applies in bulk, DELETE removes in bulk.
The skill scope is not career-relative. Career, section and skill-group assignments carry the career; a skill-scope assignment keys off the skill alone and returns
careerId: null. The four scopes are deliberately not squeezed into one shape.GET /api/v1/skill-groups/{id}/trainer-count counts people carrying an enabled trainer-designating flag for the group.
Not published
FlagType — every assignment row internally duplicates the flag’s display name as a string, and it drifts when the flag is renamed. The API publishes the flag reference only.