Pomavo's first foundation release gives you the building blocks for a configurable, multi-tenant ticketing system. You can shape ticket types, control data entry, enforce workflow rules, and manage organization-wide settings from one place.
Multi-tenant organizations and session-based access
Pomavo is organized around the organization, which acts as the tenant boundary for tickets, templates, workflows, members, settings, API keys, and background work. Every record is scoped to an organization, and the tenant context is established at the edge of each request before data reaches the API, search index, or job pipeline.
That matters when you are running multiple teams, clients, products, or business units in the same SaaS platform. A ticket in one organization is not just hidden from another organization in the UI, it is separated by the data-access model and by the token context used by services.
Authentication is handled by a dedicated Auth service. It manages sessions, supports email and password login, supports GitHub OAuth, and issues signed tokens that other services can verify independently. The application API receives those tokens and checks permissions, but it does not own passwords or the login flow.
The security model is intentionally layered: identity confirms who you are, tenant context confirms where you are acting, and permissions confirm what you can do. See Security Model and Organization Settings for the full model.
| Foundation piece | What you configure | Why it matters |
|---|---|---|
| Organization | Workspace name, slug, default theme, members, join requests, permissions | Keeps teams and tenant data separated |
| Session auth | Email and password, GitHub OAuth, signed tokens | Gives users a secure interactive login flow |
| API keys | Organization-bound machine access | Lets integrations operate inside one tenant |
| Permissions | Member capabilities and defaults | Controls sensitive operations consistently |
| Exports | Tickets and templates as JSON | Supports backup, migration, and audit needs |
Templates define the shape of work
Templates are now the foundation of every ticket. A template represents a ticket type such as Bug Report, Task, Epic, or User Story, and it owns the fields, screens, sequence numbering, workflow assignment, icon, and color for that type of work.
This lets you model the difference between a bug and a feature request instead of forcing every team into one flat issue shape. A bug can ask for reproduction steps and severity. A feature request can capture business value, target release, and stakeholder context. A task can stay lightweight.
Each template can start from a built-in preset or from a blank configuration. As your process changes, you can add fields, adjust screens, update visual identity, and keep using the same template as the canonical definition of that work type.
Templates also make tickets easier to scan. Ticket lists, boards, search results, and ticket headers can show the template icon, color, and sequence number together, so you can quickly tell what kind of work you are looking at.
Custom fields capture the data your process needs
Custom fields give each template its own data model. The Fields system supports simple values, dates and times, people, booleans, rich text, and choice-based fields with configured options.
| Field type | Use it for | Important behavior |
|---|---|---|
| Text | Short labels, IDs, external references | Single-line input |
| Textarea | Descriptions, notes, reproduction steps | Rich text, mentions, and inline attachments |
| Number | Estimates, costs, counts, scores | Numeric filtering and reporting |
| Dropdown | Priority, severity, component, resolution | Single choice with optional icons and colors |
| Multi-Select | Labels, affected areas, environments | Multiple configured choices |
| Date | Due dates, milestones, target dates | Date picker values |
| Time | Time-only scheduling data | Time picker values |
| Date & Time | Exact incident or release moments | Combined date and time picker |
| User | Assignee, reviewer, owner | Single or multi-user assignment |
| Checkbox | Triage flags, compliance checks | Boolean toggle |
Field configuration includes whether a field is required, a default value, and a description that appears as helper text. Dropdown and multi-select fields can define options, and those options can carry their own icon and color so values stay recognizable on dense ticket views.
User fields include a multi-user toggle. That lets you decide whether a field should point to one person, such as an assignee, or multiple people, such as reviewers or stakeholders.
Screens control create and detail experiences
Screens let you decide which fields appear when a user creates a ticket and how fields are arranged on the ticket detail page. This keeps ticket creation focused while still preserving full detail for later editing.
The Create Screen is optimized for intake. You can show only the fields that must be filled at creation time, such as title, severity, customer, and first owner. Fields that are useful later, such as root cause or resolution notes, can stay off the create form.
The Detail Screen is the full layout for ongoing work. Fields are organized into named sections, and sections can group related information such as Technical Details, Business Context, Triage, Ownership, or Release Planning.
| Screen area | Controlled by | Example outcome |
|---|---|---|
| Create Screen | Field visibility and order | A fast create dialog with only required intake fields |
| Detail Screen | Sections and field placement | A ticket view grouped by context, ownership, and delivery |
| Section order | Drag and drop layout editing | Most important information appears first |
| Field visibility | Per-screen configuration | Later-stage fields do not slow down initial creation |
The visual layout editor supports drag and drop field arrangement. You can move fields between sections, reorder sections, and hide fields from the create flow without removing them from the template.
Sequence numbering makes every ticket referenceable
Every ticket receives an automatic sequence number based on its template's Sequence Config. Sequence numbers make tickets easy to cite in meetings, commits, comments, release planning, and support conversations.
| Template | Prefix | Padding | Example |
|---|---|---|---|
| Bug Report | BUG | 5 | BUG-00001 |
| Task | TASK | 5 | TASK-00001 |
| Epic | EPIC | 4 | EPIC-0001 |
| User Story | US | 5 | US-00001 |
A sequence configuration includes the prefix, separator, padding, and start value. The default separator is typically a hyphen, and padding gives you stable ticket keys such as BUG-00001 instead of BUG-1.
Sequence numbers are unique within a template. That means BUG-00001 and TASK-00001 can both exist, which keeps each work type's numbering easy to read while avoiding cross-template contention.
In the ticket detail header, the sequence number appears with the template icon and color. This combination gives you a compact, human-readable identifier that still carries visual context.
Icons and colors create visual identity
Template Icon & Color settings give each ticket type a recognizable identity across the application. Icons come from the Lucide icon library, and colors are used on ticket type badges, board indicators, navigation highlights, and status badges.
A good visual system reduces cognitive load. If bugs are red with a bug icon, epics are purple with a layers icon, and tasks are blue with a check icon, your team can scan boards and search results faster.
| Visual element | Where it appears | Recommended use |
|---|---|---|
| Template icon | Ticket headers, lists, boards, navigation | Pick a simple symbol that reads at small size |
| Template color | Badges, indicators, highlights | Use distinct colors for types that appear together |
| Live preview | Template editor | Check the visual language before saving |
The key is consistency. Once your team learns the visual vocabulary, a board card or search result can communicate type before anyone reads the full title.
Workflows enforce legal state transitions
Workflows define the lifecycle of a ticket as a visual state machine. States are nodes, transitions are edges, and a ticket can only move through transitions that the workflow allows.
Common states include To Do, In Progress, In Review, Done, and Abandoned. You can add custom states for your process, then connect them with transitions that represent valid movement.
| Workflow concept | What it does | Example |
|---|---|---|
| State | Represents a stage in the process | In Review |
| Transition | Allows movement from one state to another | In Progress to In Review |
| Category | Groups states by meaning | Initial, active, terminal |
| Designer | Edits the state machine visually | Drag nodes and draw edges |
| Assignment | Links a template to a workflow | Bug Report uses Engineering Workflow |
Only legal transitions appear as action buttons on the ticket detail header. If your workflow does not allow a ticket to jump from To Do directly to Done, the UI does not offer that move.
Multiple templates can share the same workflow when they follow the same process. A Bug Report and Task might both use an engineering workflow, while an Incident template might use a separate escalation workflow.
Organization settings bring administration together
Organization Settings centralize workspace-wide configuration. From there, you can manage the organization name and slug, set a default theme, invite members, review join requests, configure permissions, and define default permissions for new members.
Default member permissions are especially important for onboarding. Instead of manually assigning the same capabilities to every new teammate, you can decide which permissions new members receive when they join the organization.
Exports are also available from organization settings. You can export tickets as JSON, including field values, links, status, and template information. You can also export templates as JSON, including fields, workflow states, transitions, and sequence configuration.
This foundation is what the next releases build on: richer search, comments, projects, theming, boards, reports, and operational tooling all depend on these configurable tenant, template, ticket, and workflow primitives.