Description

The documentation below has been prepared as a proposal for how "Ticket WFAs" should be titled and described. The purpose of this is to facilitate visual inspection, ordering of WFAs, identification of content and general management. The naming convention also reduces the risk of human error and thus operational disruptions. 

NAMING CONVETIONS FOR WFA TITLE

STAGES (Written in CAPS)

[DEV, TEST, PROD, REVIEW]

Explanation of STAGES:

• DEV = WFA is currently being developed

• TEST = WFA is currently being tested

• PROD = WFA has been put in production. Changes to this WFA needs authorization from Freshservice system manager

• REVIEW = WFA is not working as intended and is currently in review by Customer or Synerity

• TBD = A WFA that anyone has marked “To be deleted”

• OTD = A WFA that customer has given “OK to delete”

TYPES (Written in CAPS):

• INC

• SRQ

• BOTH

Explanation of TYPE

• INC = WFA affect an incident

• SRQ = WFA affects a service request

• BOTH = WFA affects either an incident or a service request

EVENT (Written in CAPS)

The EVENT is the actual event the WFA is triggered by. It can be important that this is part of the naming convention since the order of events can have impact of the WFA execution.

[CREATE, UPDATE, DELETE, ITEMADD, ITEMUPDATE, FIELD, MULTI, OTHER]

Explanation of EVENTS

• CREATE = The starting event of the WFA is when something is created (raised)

• UPDATED = The starting event of the WFA is when something is updated

• DELETED = The starting event of the WFA is when something is deleted

• ITEMADD = The starting event of the WFA is when a requested item is added.

• ITEMUPDATE = The starting event of the WFA is when a requested item field is updated

• FIELD = The starting event of the WFA is when a ticket is changed FROM something TO something

• MULTI = The starting event of the WFA is more than one event

• OTHER = The starting event of the WFA is something else not captured by any other of the other EVENT abbreviations.

TAGS (Written in CAPS)

Explanation of TAGS

A tag can be anything to highlight the purpose of the WFA. It might be that it's related to a business function, a vendor or any other kind of purpose.

Title (Written in Lower case)

The title of the WFA summarizes the purpose of the WFA in free text. This can be described in any desired way. Recommended is to hold the titles as short as possible.

Examples of titles

• Assign Ticket to the First Responder

• Category-Based IT Ticket Routing

• Requester respond on closed ticket

In summary the above areas for naming convention is added together to form the rule set for giving the WFA a title.

[STAGE - TYPE - EVENT - TAG - Title]

Examples of Workflow automation title

• DEV - SRC - RAISED - DUSTIN - Create computer order

• TEST- SRC - RAISED - DUSTIN - Create computer order

• PROD - SRC - RAISED - DUSTIN - Create computer order

• PROD - BOTH - MULTI - ASSIGNMENT - Assign Ticket to the First Responder

• PROD - BOTH - CREATE - ASSIGNMENT - Category-Based IT Ticket Routing

NAMING CONVETIONS FOR WFA DESCRIPTION

The below abbreviations are recommended to be part of the WFA description. This makes it easier for system administrators to understand the contents of the WFA without going in to them one by one. If a WFA has more than one, just add them comma separated.

Abbreviations and explanation for WFA description

• WEBR = WFA hold at least one web request node

• MAIL = WFA sends some kind of email

• TIME = WFA holds a timer node

• ORCH = WFA handles orchestration requests

• COBJ = WFA holds at least one custom object node

Workflow automation description

The description of a WFA is important because it lets you give that extra detail to the automation and can therefore explain the purpose in more depth. It's also here possible to manually handle versioning of the WFA.

Versioning

It's recommended to incorporate some type of versioning of the WFA's description. Even if WFA's don't have a classic versioning structure it makes it easier for incident and change managers to refer to versions when altering WFA. Another document is under work to more clearly define how versions of WFA are managed, maintained and retained.

Example of versioning

• DEV = Versions dedicated to WFAs in the stage DEV are 0.1 – 0.9, 1.1 – 1.9, etc

• TEST = Doesn't have any type of versioning. Versions are not to be changed during testing.

• PROD = Versions dedicated to WFAs in the stage PROD are 1.0, 2.0, etc

• REVIEW = Doesn't have any type of versioning. Versions are not to be changed during reviews.