This page is for Stockler's building a ticketing database, it explains the mandatory fields and gives good practices on other fields.
In tickets tables, dedicated formula
properties must be used to delimitate sections and must be identified with these icons: ⏬ (Chevrons Down) for sections and ↪️ (Square arrow uturn right square) for “sub-sections”
e.g. section for inputs, section for outputs, section for computation
e.g. ‣,
-- Outputs --
- Illustration
Properties “case rules”:
🤓 Fields useful for a creator or a reader of a Ticket / Task should be in Words Like This
(words with capital letters separated by spaces)
➗ Fields for internal computations, or for specific views, should in snake_case
(lower case with dashes between words)
All those fields must be present in all ticketing system.
Title
Type: String
Display: Should always be on top and always shown.
When creating a ticket: The Title
must be set. It should specify the topic of the request.
Description: This field is mandatory in Notion. It should describe the issue concisely, in no more than 32 characters.
Severity
Type: Select
Display: Should always be the first (1) field under the title and always shown.
When creating a ticket: The Severity
must be set. Please refer to Ticket Severity for which severity to select.
Description: Drop down list of 5 values SEV1, SEV2, SEV3, SEV4, SEV5. Please respect the color code of Ticket Severity
Status
Type: Select
Display: Should always be the second (2) field under the title and always shown.
When creating a ticket: The Status
must be set to 0 - Pending Workforce, or On Hold. By default it should be 0 - Pending Workforce, tickets that require validation may be created with status On Hold.
Description: The possible statuses may vary from team to team but must have the mandatory statuses with the right colour. Statuses should be prefixed by their chronological order, always start by 0 - Pending Workforce and -1 - Dropped should always be prefixed by -1
. For example, 0 - Pending Workforce, 1 - Started, 2 - Done, -1 - Dropped.
Reminder
:
Assignee
Followers
Created by
Updated at
Created at
<aside> ⚠️ Sanity checks must not be done through views: it is hard to understand why the ticket is invalid, and adding a check requires updating all views.
</aside>
Sanity checks must respect the following principles:
Classical Sanity Checks should include (valid for all Tickets & Tasks)