14 Replies Latest reply on Dec 6, 2018 4:32 PM by Nicolas Roome

    New Hire Process

    Klint Nielsen

      Would like to configure a new hire process within footprints in which HR would initiate the master ticket that spawns 4 subtasks but they each have their own quick template

       

      Same Workspace
      Record Defination 1: User Access (master ticket with quick template)
      Record Definiation 2: Tasks (4 subtasks, each with their own quick template)
      Link: Master/Subtask

       

      If all 4 subtasks created at once, how would the workflow process look like (and in which record definition):
      Subtask 1 -> Subtask 2 -> Subtask 3 -> Subtask 4 so that not all 4 subtasks are being worked on at once because there are some dependencies and have different templates.

       

      Tried sequencing and using a certain field to use as the workflow process but haven't found a good way to notify the next subtask assignee that they can start working on their subtask since they are created once the master ticket is created.

       

      The subtasks inherit most of the fields from the master, the only difference is each template has a different description for their particular task to do for the process and the type of work being performed.

       

      Any guidance would be greatly appreciated.

        • 1. Re: New Hire Process
          Vern Meyer

          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.

          • 2. Re: New Hire Process
            Vern Meyer

            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.

            1 of 1 people found this helpful
            • 3. Re: New Hire Process
              Klint Nielsen

              Whoa that's a lot to chew.

               

              Appreciate the feedback Vern! That sounds like a feasible solution. We'll see if we can set that up.

               

              Very much appreciated!

              • 4. Re: New Hire Process
                Nicolas Roome

                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.

                • 5. Re: New Hire Process
                  Vern Meyer

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

                  • 6. Re: New Hire Process
                    Vern Meyer

                    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?

                    • 7. Re: New Hire Process
                      Nicolas Roome

                      You're speaking English right?

                      • 8. Re: New Hire Process
                        Vern Meyer

                        Haha, maybe thats the problem!

                        • 9. Re: New Hire Process
                          Christopher Bradfield

                          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.

                          • 10. Re: New Hire Process
                            Klint Nielsen

                            Hey Christopher,

                             

                            Would mind sending me some screenshots of your process as that how our process start and would like to see if that's the way we want to go with.

                            • 11. Re: New Hire Process
                              Stuart White

                              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

                              1 of 1 people found this helpful
                              • 12. Re: New Hire Process
                                Klint Nielsen

                                This is awesome Stuart! Thanks for documenting the process

                                • 13. Re: New Hire Process
                                  Vern Meyer

                                  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.

                                  • 14. Re: New Hire Process
                                    Nicolas Roome

                                    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: