This page is for Stockler's building a ticketing database, it explains the mandatory fields and gives good practices on other fields.

🗺️ Structuring and naming properties

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 --

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)

Mandatory

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

Reminder:

Followers

Created by

Updated at

Created at

🧹 Sanity checks

<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)

Relations