We have this functionality built! The only problem is that to keep it active, we've had to stay on an old version of Footprints. 12.1.05 is the latest version we've been able to do it on.

Theres actually a few way to do this, they're just currently broken (and have been for over 2 years at this point).

I'll try to find more information, my account manager was looking into this, but they fell slient.

So in 12.1.03 this functioned perfectly:

- Setup a workflow with steps for each Subtask that needs to be done before another.

- Create after save rules (inside master ticket workflow) with "On-enter" triggers to create the subtask tickets.

- Create after save rules (inside master ticket workflow) with "On Linked Item Update: [Master/Stubtask: Subtask]" triggers, in the criteria use "Generic Linking Every [Master/Subtask: Subtask]" with the Sub-Criteria being whatever you completed status might be for the ticket. The action would be to move into the next status which you have your next subtask waiting to be created with the above rule.

Worked great. In our environment we had an approval and 7 sub tasks, some that had to wait for other to be completed. We were able to condense the sub-task steps down to 3 steps after the approval. When it was approved, the master ticket would go into the first sub-task step. It waits there and anytime the sub-task is updated, the last rule runs to see if its status is complete. If it was, the rule would run and move the master into step 2 and fire off more sub-tasks and wait until their completed again.

Now...The bad news

In 12.1.04, defect 99569 was produced - https://communities.bmc.com/docs/DOC-68936

PROBLEM:

If a ticket is moved to a workflow state that has an 'On Enter' rule (or out of a workflow state that has an 'On Exit' rule) via another rule being triggered from 'On Linked Item Update', the workflow rule does not fire.

Well dang, BMC gave me a "Yep we know its a defect now, have a nice day" response. I asked for a workaround, none.

Since the trigger "On Linked Item Update" seemed to be a posible hinge, we went time based. Yay! It works again. It possibly extends the timeframe of our requests because it was decided that we'd only have the rule run every 6 hours.  Oh well, it works.

In 12.1.06 defect DRZNZ-1792 was produced-

PROBLEM:

If an After Save rule is configured with a Time-based trigger, the Create New Record action is not completed.

Welp there goes our workaround of creating the tickets automatically based on time.

Currently in 20.18.02

                - DRZNZ-1792 is still an issue.

                - 99569 from 12.1.04 was never addressed. I recently resubmitted and got a new defect ID of DRZNZ-4970.

Hi Vern Meyer

Defect # 99569 became DRZNZ-587 per my records. Could you reach out to your support provider and verify if 587 and 4970 are duplicates.

Thanks for that! Just reached out to BMC to see if they are duplicates.

Haha man this is confusing:

-From my account manager who escalated the request:

99569: the defect was fixed in 20.18.02 and it is now tracked as DRZNZ-587

DRZNZ-1792 – We have taken a run at fixing this defect, but the underlying root cause has proven challenging.  We are anticipating solving this in FootPrints 2019 R1

-From support after asking  is 587 and 4970 were duplicates:

Defect DRZNZ-4970 looks similar to DRZNZ-5029  which is regression of DRZNZ-587.

So DRZNZ-587 is fixed, but DRZNZ-5029 and DRZNZ-4970 are the same issue and they aren't fixed?

You're speaking English right?

Haha, maybe thats the problem!

Hey Vern,

This has been why I have avoided using any type of sequencing in workflows, the rule behavior was not always predictable. For New Hires as the dependency is usually the the network account I move the master that HR enters (or whoever) over the the team that sets up the AD account and then when they mark that they have completed the account, I move the master ticket to its next owner (usually desktop or the like) and then create all the sub-tasks. With this I can avoid any sequencing.

I have had a few cases were there were other dependencies that required something else, but they have been the few "one off" items.

I documented a process to sequence subtasks for a new hire process where, once the master is created, all four subtasks are created. This will only work for a static process. I've found no way to sequence subtasks on the fly.

SEQUENCING SUBTASKS ON STATIC PROCESSES IN FPSC V.12 | RightStar

I'd like to note that Stuarts document is prettly clearly working around the defects I stated. You should be able to create the ticket dynamically with a workflow, since you can't their work around has you create all tickets at the beginning of the process change their status to bring them into a view as needed.

Let's just hope that BMC doesn't break it with an update like they did mine twice.

Stuart White, for your end note:

When the New Hire ticket is created, there are four subtasks created. As each stage is Resolved, the next stage of subtasks is set to the Open status. These subtasks will remain as unable to edit until the logged in user refreshed the web page or performs a logout and login.

This is a defect in FootPrints: