Tickets follow a clear lifecycle with six standard statuses. Who may trigger which status change depends on role and previous status. This article describes each status in detail, the typical transitions, and automatic status changes via subtasks.
The six standard statuses
ZEP uses the following six statuses. Each newly created ticket starts in status new.
new
Initial status of every ticket. No work logged yet. In this status, the creator can still enter planned hours (if enabled in the basic settings) and the ticket can easily be reassigned to a different project or deleted.
in process
Processing in progress. Project times can only be booked on a ticket once it has reached this status. If an employee changes the status from new to in process without an assignee set, they are automatically set as the assignee.
done
Processing completed. Ticket awaits acceptance by creator, customer contact person or project manager. On each transition to done, ZEP sends a notification to creator and project manager (if enabled in the notifications master data).
accepted
End status after successful acceptance. No more project times can be booked on this status. From a workflow perspective the ticket is closed but remains in the database for reports and history.
rejected
End status when the solution is not accepted or the ticket is no longer pursued. Setting this status requires a comment as justification. Rejected tickets remain in the database and can be reactivated by authorised users (administrators, project managers, creator) by setting the status back to new or in process.
billed
End status after billing (only relevant in specific invoicing module constellations). Documents that the corresponding invoice has been issued. Status transitions out of billed are locked.
Transitions and permissions
Which follow-up statuses are reachable from the current status depends on the role and assignment to the ticket. The overview below shows the typical transitions.
Standard transitions
From new: in process, done, or directly accepted (with corresponding permission).
From in process: done, back to new, or directly accepted.
From done: accepted, rejected, back to in process, or back to new.
From rejected: back to new or in process (reactivation by authorised users).
From accepted: no normal follow-up status. Administrators can reset in special cases.
Permission per transition
Who may trigger which transition depends on the role of the logged-in user. The central rule: the assignee may set their own work to done; acceptance (to accepted or rejected) is handled by creator, project manager with budget responsibility, department manager (with Locations & Departments module) and administrators.
Note: With customer access active, customer contact persons may set tickets in status done to accepted or rejected, provided the per-project permission is configured. More in the article Customer Access to the Ticket System.
Shortcut "Advance status"
From the ticket overview, authorised users can set the status directly without opening the full edit dialog. Via the arrow icon or the action Set status, a popup with three fields opens: next status, assignee (prefilled with the logged-in user if empty) and optional comment. This lets you record status changes including a comment in a single click.
Automatic status transitions via subtasks
Tickets with subtasks follow additional automation rules. These are hard-wired in ZEP and cannot be disabled:
When a subtask changes to in process, the parent ticket automatically goes to in process as well, provided it was still in status new.
When a subtask changes to rejected, the parent ticket automatically goes to rejected, provided all other subtasks are also in an end status.
When all subtasks reach status done or accepted, ZEP asks on the next save whether the ticket should also be set to done.
When a ticket in status done is manually reset to in process, all associated subtasks also revert to in process.
As long as not all subtasks are in an end status, the ticket cannot be finally closed. Details on subtask management in the article Manage Subtasks.
Effect on bookings and editing
The status determines what can still be changed or booked on the ticket:
On closed tickets (status accepted or rejected) project times can typically no longer be booked. The exact lock rules depend on the role permissions.
Rejected tickets remain in the database and can be reactivated if you have edit permission.
A project change is only possible if no project times are booked on the ticket. Otherwise via the bulk action in the ticket overview (see article View and Manage Tickets).
Acceptance by customer contact person
With customer access active, the customer contact person accepts tickets directly via their login. In the per-contact permissions you control whether acceptance is allowed and whether rejection is also available. When rejecting, a comment as justification is mandatory — the current assignee receives an email with the note. Details in the article Customer Access to the Ticket System.