Tickets

Tickets are the human work-management layer on top of your plants — the place where investigation, assignment, discussion, and resolution actually happen. Where an event is a machine-detected signal, a ticket is the workspace your team owns: who is working on it, what was tried, and how it ends.

Tickets Concept

Your plants raise events automatically — a grid shutdown, an overproduction cap, a logger losing its source. Those events are deliberately lightweight: they record what was detected, where, when, and how serious. They are not the right place to track the work that follows.

A ticket is that follow-up. You open a ticket to investigate a problem, hand it to a colleague, gather notes and findings in one thread, link the components and events it concerns, and close it once the situation is resolved. Every change is recorded, so months later you can reconstruct exactly what happened and who did what.

Events vs. Tickets

An event is a detected signal, usually automatic and read-only as a record. A ticket is the human story around it: triage, assignment, comments, and resolution. The two are linked so the signal and the work to resolve it stay connected. The free-text title and description that older events carried are being retired in favour of tickets — treat the event as the trigger and the ticket as the workspace.

Tickets are a plant sub-resource: every ticket belongs to one plant, and your access to it follows your role on that plant rather than a separate setting.

What a Ticket Holds

A ticket gathers everything about one piece of work in a single view:

Title and description — a short headline plus the full narrative of what is being addressed.
Category — what kind of work this is (see below), so tickets can be filtered and triaged by type.
Status — where the work stands in its lifecycle.
Assignee — the single person responsible for the ticket. Reassigning is recorded.
Timeline — an optional start and end time for the work, alongside the automatic creation, update, and closure timestamps.
Comments — a threaded discussion where the team works the problem out.
Mentions — pull a colleague into a ticket with an @mention; they are notified and tracked.
Links — connections to the events, other tickets, and components this work touches.
Activity feed — a complete, automatic history of every change made to the ticket.

System tickets

Some tickets are opened automatically by the platform rather than by a person. They behave like any other ticket — you can comment on them, assign them, and close them — but they are flagged as system-generated so you can tell at a glance which work the platform queued up for you.

Ticket Categories

Each ticket carries a category so your team can sort and triage work by the kind of problem it represents:

Category	Use it for
Maintenance	Planned or routine servicing and upkeep
Defect	A faulty component or equipment failure
Communication	Connectivity or data-acquisition problems with a source
Shutdown	Work tied to a grid or external production stop
Environmental	Conditions driven by weather, soiling, shading, or the surroundings
Informative	A record kept for awareness, with no action required
General	Anything that does not fit the categories above

Ticket Lifecycle

A ticket moves through a clear status sequence so everyone can see where the work stands:

Open — created and waiting for initial triage.
Detected — the underlying issue has been identified and confirmed.
In Progress — someone is actively working on it.
Closed — the work is finished and the situation is resolved.

A closed ticket can be reopened if the problem returns, so a recurring issue keeps its full history together rather than spawning a fresh, disconnected ticket each time. Closing and reopening are both recorded in the activity feed, along with who did it and when.

Comments and Mentions

The discussion thread is where the actual problem-solving happens. Anyone working a ticket can:

Comment to record findings, decisions, and next steps.
Edit or delete their own comments — edited and deleted comments are marked rather than silently changed, so the trail stays honest.
Mention a colleague with @ to draw them into the ticket. The platform tracks who was mentioned, by whom, and when, and notifies the mentioned user.

The ticket also records which users were notified about it and which have seen it, so you know whether the right people are aware of an open issue.

Linking the Bigger Picture

A ticket rarely stands alone. You can connect it to the rest of the platform so context follows the work:

Event links — reference the events that triggered or relate to the work. A grid-shutdown event and the maintenance ticket to fix it stay tied together.
Ticket links — reference other tickets, so related or dependent work is easy to navigate between.
Component links — attach the specific parts of the plant the ticket concerns (a logger, inverter, GAK, string, feed-in meter, or irradiation sensor), and search the plant's components to find the right one. This is the same linking model used by events, so the component evaluation view and the ticket stay consistent.

Start from an event

When an event needs investigation or a fix, open a ticket and link the event to it. The event remains the objective record of what the platform detected; the ticket carries the assignee, discussion, mentions, component links, and the full history of the work.

Activity History

Every ticket keeps an automatic activity feed — a chronological audit of everything that happened to it. You never have to maintain it by hand; the platform records each action as it occurs:

Creation, closing, reopening, and deletion.
Title, description, category, and status changes — captured with the previous and new value.
Assignment, reassignment, and unassignment.
Comments added, edited, or deleted, and users mentioned.
Components linked or unlinked, and events or other tickets referenced or unreferenced.

This feed is the ticket's source of truth for accountability: warranty disputes, audits, and post-incident reviews all draw on it, and it cannot be quietly rewritten after the fact.

Finding and Reviewing Tickets

Tickets are retained as a long-term record so you can manage day-to-day work and review history later:

List and filter — browse tickets across the plants you can access, filtered by plant, category, status, or assignee, and sorted to surface the newest or most urgent first.
Detail view — open any ticket to see its description, comments, linked events and components, notification and seen tracking, and the complete activity feed.
Historical record — closed tickets stay available, keeping the full story of past work and recurring problems intact.

Access and Permissions

Tickets are a plant sub-resource, so access follows your job role on the parent plant — not a separate per-ticket setting. Anyone who can view a plant can read its tickets. Beyond that, the platform distinguishes technical from commercial responsibility:

Technical roles — Operators and Technical Managers (and the equivalent organization roles) get full ticket administration: create, edit, assign, comment, close, reopen, and delete.
Asset Manager (Commercial) can read and create tickets, but cannot close, reopen, or delete them — commercial oversight without changing the technical resolution state.
Viewers can read tickets but not change them.

Cooperators who hold the required job role on a shared plant are included on the same terms. See the Permission System for the complete role model.

Events — the machine-detected signals that tickets are opened to investigate and resolve
Component Evaluation — the per-component health view tickets link back to
Permission System — the job roles that govern who can read, create, and administer tickets
Reports — periodic documentation that draws on resolved issues and production losses