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 in the heading section
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
Assignee
Type: Person
Display: Should always be the second (2) field in the heading section
When creating a ticket: If the ticket is in 0 - Pending Workforce the Assignee must not be set by you, if the ticket waiting for validation the Assignee must be you. A template may set by default an Assignee.
Description: The Stockler in charge of making this ticket move forward.
Status
Type: Select
Display: Should always be the third (3) field in the heading section
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.
Mandatory:
0 - Pending Workforce (Colour = Red): This status indicates the ticket is ready to be handled. If you want some time to write your ticket please create it with no status and set the status to 0 - Pending Workforce when you've finished. If you need some validation please create the ticket with status On Hold and follow §How to ask for validation ? of [Shared] Inter Team Communication.
1 - Started (Colour = Blue): The team has started working on it. The Assignee must be set at this point.
On Hold: The Assignee needs either validation or information in order to resume working on the ticket. Whenever a ticket is On Hold, the On Hold Reason should be specified either as a part of the template or in the ticket’s comments. Please use On Hold rather than In Discussion, or Blocked.
2 - Done (Colour = Purple): The team has finished handling your ticket.
-1 - Dropped (Colour = Grey): The team has deemed the ticket not to be of its responsibility or you've decided to handle the ticket yourself. Please do not delete tickets after they have been reviewed.
Other frequent statuses are:
Accepted (Colour = Yellow): The team has reviewed your ticket and validated it had all the information required to handle it.
Scheduled (Colour = Green): The team has scheduled a handling date.
In Review (Colour = Pink): The ticket has been done is and is being or waiting a review from another team member.
Reminder:
Type: Date, following date format guidelines
Display: Should always be the fourth (4) field in the heading section
When creating a ticket: The Reminder should not bet set by you except if you're waiting for validation. It should be set a member of the team handling the ticket.
Description: This field is to generate a notification at a given date to all followers, creator and assignee of the tickets. It should be used for On Hold ticket to ensure it doesn't go stale.
Followers
Type: Person
Display: Should always be the one before Created by and hidden when empty.
When creating a ticket: The Followers should not be set by you. A template may set by default some Followers.
Description: The Stocklers interested in following this ticket. This is used by Stocklers to have custom views with tickets they want to follow. You can use this field to notify a third party Stockler of a ticket.
Created by
Type: Created by
Display: Should always be the one before Updated at and always shown.
When creating a ticket: The Created by must be set to you. Notion should handle this automatically.
Description: The notion field Created by
Updated at
Type: Last edited at, following date format guidelines
Display: Should always be the one before Created at and always shown.
When creating a ticket: The Updated at must be set to the day you've created the ticket. Notion should handle automatically this.
Description: The Notion field Last edited at
Created at
Type: Creation time, following date format guidelines
Display: Should always be the last field and always shown.
When creating a ticket: The Created at must be set to the day you've created the ticket. Notion should handle this automatically.
Description: The Notion field Creation time
<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:
sc_<sanity_check_name>.Sanity Check and that’s the concatenation of the sub sanity checks fields.🛂 Invalid that lists all elements [not Done or Dropped] and with [Sanity Check not empty]Classical Sanity Checks should include (valid for all Tickets & Tasks)