Ticket creation workflow

[Shadowtech87]

I was wondering if the workflow condition sets for tickets being created/updated etc. could include access for the ticket categories and subcategories? I was trying to setup a method when a ticket was created that if a category/subcategory is X to assign the ticket to a specific team or analyst.

If you already have a workflow intended for this that I’m missing just let me know.

[edmozley]

Hi @Shadowtech87 - you weren't missing anything: a workflow could set a category but not check one. That's fixed in 5.0.0.

Category is now a condition on every ticket trigger. For your example:

• Trigger: A ticket is created
• Condition: Category is Hardware
• Action: Assign ticket to team (or Assign ticket to analyst)

Subcategories: by default, choosing a category also matches everything beneath it, so Hardware catches Hardware → Laptop too. If you'd rather each workflow names its subcategories exactly, change it in Tickets → Settings → Categories → Categories in workflows. The workflow editor shows a tip under a category condition saying which way it's set, with a link to that setting.

Tickets categorised later: email tickets usually arrive with no category and get one when somebody triages them, so "when created" would miss them. There's a new trigger for that, A ticket's category changes - use the same condition and action with it, and a ticket is routed the moment it's given its category.

The run history also says when a match included a subcategory, so it's easy to see why a workflow ran.

Thanks for the idea - it filled a real gap.

[Shadowtech87]

Thanks for the update, applying this today. I have a question. As I'm setting things up and have similar questions like this or ideas, are the github discussions the best place to put them? I have several other things I have noticed and was looking for clarification. One example is the Starters & leavers module, when creating a case it creates tasks which seem to flow more in the project management workflow. Where I have always used tickets in my original system, it just seems to be better for a single pane of glass for work to do. Was wondering about the thought process on this, or if there is something I am missing. Mainly having a single pane of glass to monitor for work be the tickets is what I am used to and perhaps there is something here that I am not thinking of.

…

On Wed, Nov 11, 2026 at 7:17 PM Ed Mozley ***@***.***> wrote: Hi @Shadowtech87 <https://github.com/Shadowtech87> - you weren't missing anything: a workflow could *set* a category but not *check* one. That's fixed in *5.0.0*. *Category is now a condition on every ticket trigger.* For your example: - *Trigger:* A ticket is created - *Condition:* Category is *Hardware* - *Action:* Assign ticket to team (or Assign ticket to analyst) *Subcategories:* by default, choosing a category also matches everything beneath it, so *Hardware* catches *Hardware → Laptop* too. If you'd rather each workflow names its subcategories exactly, change it in *Tickets → Settings → Categories → Categories in workflows*. The workflow editor shows a tip under a category condition saying which way it's set, with a link to that setting. *Tickets categorised later:* email tickets usually arrive with no category and get one when somebody triages them, so "when created" would miss them. There's a new trigger for that, *A ticket's category changes* - use the same condition and action with it, and a ticket is routed the moment it's given its category. The run history also says when a match included a subcategory, so it's easy to see why a workflow ran. Thanks for the idea - it filled a real gap. — Reply to this email directly, view it on GitHub <#298?email_source=notifications&email_token=BXZP2NVSQNW2ZH63A5TIPOT5YT6P7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGUZTMOBRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19553681>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BXZP2NQCQBJK5XGPRK6JTA35YT6P7AVCNFSNUABJKJSXA33TNF2G64TZHMYTCNJSGIZDSMRYGQ5UI2LTMN2XG43JN5XDWMJRGI3TEOJUGGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BXZP2NWJZG7KRDVA76J3O7T5YT6P7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGUZTMOBRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/BXZP2NXF2DUY3EDLUE4PQPL5YT6P7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGUZTMOBRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[edmozley]

Hi @Shadowtech87

My personal preference is to use Github "Issues" for questions, bug reports, ideas etc. The reason being it's easier for me to see them and manage them all in one area.

On Starters & leavers using tasks rather than tickets - you're not missing anything, it was a deliberate choice, and it's a fair question.

Why tasks. A ticket in FreeITSM is a conversation with someone who has asked for something: a requester to reply to, an email thread, an SLA clock, a satisfaction survey at the end. A starter or leaver is a different shape - it's a plan: half a dozen jobs for different teams, each due on its own day counted from the start or leaving date (the laptop five days before, the account on the day, the access review two days after). Tasks are built for exactly that: an owner and a due date per step, checklists, the board and calendar, and the case reading its progress straight back from them. As tickets, the same starter would be six or seven tickets with nobody to reply to, SLA clocks that mean nothing, and no single place showing how close the new person is to being ready.

A single pane of glass today. If your service desk lives in the ticket queue, you can still give every case a ticket there with a workflow:

• Trigger: A starter, mover or leaver case is opened
• Action: Create a ticket - with the person's name and date in the subject, assigned to the team that should keep an eye on it

Each analyst's own steps are also in Tasks → My Tasks, with Tasks' notifications.

The honest gap: that ticket isn't joined to the case - it doesn't list the steps or close itself when the case is done. I'd like to close that properly, and the answer has to be flexible, because every organisation splits this work differently. Say Facilities and IT both use FreeITSM: one organisation wants a ticket for Facilities to make the security pass and one for IT to set up the five accounts; another splits IT across two teams, so it's two IT tickets - one for the accounts and one for MFA. So the template should decide it: each step can be raised as a task or a ticket, steps can share a ticket, and each ticket is linked to the case, with the case's progress following those tickets as they close.

I've written that up as #316, with the design here: Starters & leavers: steps as tickets. How does your organisation split a starter between teams? A real example on #316 would help shape it.

[Shadowtech87]

Were a small organization only 3 tech's

I'm the IT Admin and maintain AD account setup and the like
Our Application Admin will create accounts for our users to access their systems
and our Helpdesk tech will setup the hardware.

I was originally using Solarwinds Service Desk and i had a service catalog item that would create a master incident after collecting the data from HR.

The master incident would come to me and i would validate that we dont have a name duplication etc John Smith and a Jacob Smith both needing jsmith as a username. After that I approved the ticket and then 3 sub tickets were created and sent to the appropriate teams/users with the info they needed based on what the Service Catalog request gathered. Tickets were linked to the master ticket as well.

Finally after each sub ticket was closed i would then close out the master ticket. Was doing all this to work around what SWSD could do.

Also the info gathered from the original onboarding service catalog would include

• First Name
• Last Name
• Job Title
• Start Date
• Manager
• Main Site
• Alarm code needed
• ALT Site Access w/ alarm code as well
• Additional identification info
• Application Access levels
• Certifications

for the network account needed everything but the NPI and Clinical Certs

The help desk was just given the Start Date and the name for the PC "ORG-JSMITH" the rules when it sent the ticket would take the first initial of the first name and then concatenate that with the last name. and then prepend the organization mnemonic in front of it.

Finally the Application Admin needed all of it so that they could create the account in their systems with proper credintials etc.

[edmozley]

Thanks @Shadowtech87 - that's a really clear picture, and good news: almost all of it can be set up today.

Your old flow, in FreeITSM

Your SolarWinds flow	FreeITSM today
HR fills in a service catalogue item (name, title, start date, manager, sites, alarm codes, access levels, certifications)	A form in the portal catalogue with those questions
A master ticket comes to you to check for name clashes (John and Jacob Smith both wanting jsmith), and you approve	Require approval on the form, with you as the approver
Once approved, three sub-tickets go to the right people with only the info each needs	The form's When approved action Open a Starters & leavers case: a template with three steps - AD account for you, application accounts for your application admin, hardware for your helpdesk tech - and each step's text pulls in only the answers it needs
The master closes when the sub-tickets are done	The case is the master: it shows each step's progress, and you mark it done

Setting it up

1. Forms → build New starter with your questions (first name, last name, job title, start date, manager, main site, alarm code, alternative site access, identification, application access levels, certifications), and publish it in the portal catalogue.
2. On the form, tick Require approval before a ticket is raised, with you as the approver.
3. Starters & leavers → Settings → Templates → a Starter template with three steps, each given to the right person or team, due a number of days before the start date. Write each step's description with the answers it needs in braces - for the helpdesk, for example: Set up a PC for {First name} {Last name}, starting {Start date}. A step can have an Only if rule, so the alarm code step only appears when one was asked for.
4. Back on the form, What happens next → When approved → Add → Open a Starters & leavers case: choose the template, and set the name to {{submission.fields.First name}} {{submission.fields.Last name}}.

Now HR's request waits for you; when you approve it, the case opens and the three steps land with the right people.

Two things that don't fit yet

• The steps are tasks, not tickets. If you'd rather each one landed in your ticket queue, that's Starters & leavers: raise a template's steps as tickets, grouped per team as the template decides #316 (raise steps as tickets, grouped per team, linked to the case) - I've added your flow to it as the worked example to design against.
• Values worked out from the answers - your ORG-JSMITH PC name. Step text can drop an answer in but can't transform it yet, so I've raised Starters & leavers: work values out from the answers in step text - {First name|initial}, upper, lower, nospace... #317: ORG-{First name|initial|upper}{Last name|upper|nospace} would give ORG-JSMITH, and the same works for usernames and email addresses.

And as I mentioned, issues are easier for me to keep track of than discussions - so do follow #316 and #317, or open a new issue for anything else you spot.

[Shadowtech87]

Is it possible to edit a field on a form, while it is in the pending approval state?

So HR could enter all their info and I can have an AD Username field that is hidden. While it is still pending approval i could add in the JSMITH manually right now and then approve and the info is there at least.

Yes automation would be better but this would be a stop gap.