12 Replies Latest reply on Sep 14, 2020 8:54 AM by Anne Brock

    Incident Assignment Discussion

    John Wisdom
      Share This:

      I was unable to create a Poll on the BMC Helix Remedyforce space so going the Discussion route. I am curious how many customers rely on the OOB behavior of the Staff field being populated as the logged in user when creating incidents via the Console? We use a combination of workflow rule/field update and "Suggested Owners & Queue Auto Assignment" rules to populate the Queue field on create if the Queue is left blank on initial save. The creator can populate the Queue and/or Staff field(s) if they choose which prevents the rules from running.

       

      This OOB behavior on Staff makes rule setting around the Staff attribute overly complicated if not down right impossible. I'm thinking of submitting an idea to make the OOB behavior configurable so organizations that want Staff populated automatically with the logged in user can enable it and those of us that would rather assign to a Queue or Queue/Staff combo manually or with rules can disable it.

       

      I suspect that this OOB behavior goes back to when there was only one assignment field and it's existence today is merely technical debt. If that is the case, which I am hoping this poll/discussion will reveal one way or the other, then my idea may change to just backing out this code all together.

       

      Looking forward to hearing from as many as possible.

       

      Thanks!

        • 1. Re: Incident Assignment Discussion
          John Wisdom

          Here is a specific use case we are unable to overcome to emphasize my point. We fire an email to the customer on create. We want to fire another email to them once a Staff is assigned. That email lets them know their incident is being worked on and has the Staff persons name and contact information. Because the Staff is technically assigned to the logged in user on first save, regardless of our workflow rule/field update or "Suggested Owners & Queue Auto Assignment" rules, enabling the 'Staff assigned' rule/email alert will always result in the client getting two emails on create. This is obviously no good.

           

          The screen shot below is the Incident History on a newly created incident. As you can see on create it automatically "changes" Staff from blank to me (the logged in user) as well as the Current Owner to me as I am not specifying a Queue. Our workflow rule/field update runs consistent with categorization and, in this example, assigns to the "IT Support Center" queue thus changing the Current Owner and clearing Staff.

           

          2020-09-11_9-13-49.png

           

          Again, any thoughts anyone has on this would be appreciated.

           

          Thanks.

           

          • 2. Re: Incident Assignment Discussion
            Paul Donders

            Hi John,

             

            Do you have a screenshot of your workflowrule?

             

            Paul Donders

            2Grips

            • 3. Re: Incident Assignment Discussion
              John Wisdom

              Hi Paul

               

              Which one? The one that fires the field update to assign to IT Support Center or one of the ones that fires the email alert to the client?

              • 4. Re: Incident Assignment Discussion
                Paul Donders

                The one around the email, as that one is executing twice if I hear you correct

                 

                Paul Donders

                2Grips

                • 5. Re: Incident Assignment Discussion
                  John Wisdom

                  It doesn't actually fire twice. It fires even when the Staff field is not technically populated. As a result the client would get an email that the incident was created and at the same time that i was assigned to whomever the logged in user was, even though the Staff field on the record is blank.

                   

                  2020-09-11_13-02-57.png2020-09-11_13-03-39.png

                   

                  This is the rule for 'assigned to Staff':

                  (BMCServiceDesk__state__c = True) && (  BMCServiceDesk__Type__c = "Incident")&& (NOT ISBLANK( BMCServiceDesk__FKOpenBy__c))

                  • 6. Re: Incident Assignment Discussion
                    Paul Donders

                    What if you include && queuename not equal to Null!?

                     

                    Paul Donders

                    2Grips

                    • 7. Re: Incident Assignment Discussion
                      John Wisdom

                      The Queue can never be null. We have a rule in place that does not allow a record to be saved without a queue.

                       

                      The issue is that Staff is being populated out of the box with the name of the logged in user. We overcome that with our assignment rules and workflows but it doesn't change the fact that each incident believes it is initially assigned to a specific person.

                      • 8. Re: Incident Assignment Discussion
                        Paul Donders

                        Sorry bad..

                         

                        Incl in the rule $user <> staff

                         

                        Paul Donders

                        2Grips

                        • 9. Re: Incident Assignment Discussion
                          John Wisdom

                          Sorry, but why? Not following what that would be addressing.

                           

                          Also, while I absolutely appreciate the help on this rule, I don't want others to think that was the purpose of this discussion. I am very much interested in knowing if there is anyone who still relies on the OOB behavior for incident assignment rather than using workflow rules and suggested owners & queue auto assignments.

                           

                          Thanks again

                          • 10. Re: Incident Assignment Discussion
                            Paul Donders

                            That addition to the rule prevents the email to fire when the current user is set as staff.

                             

                            Ps i would not even send an email with the assigned staff. It can and will be a team that provided the support, not the individual. What if that person is out of office, or contacted directly, outside of RF

                             

                            Paul Donders

                            2Grips

                            • 11. Re: Incident Assignment Discussion
                              John Wisdom

                              Ah, I see. That actually misses the mark.

                               

                              I'm doing a poor job of explaining the use case. The assignment to a specific Staff person is sort of the official GO or response to the customer. This is usually that Staff person on the assigned Queue assigning it to themselves. We don't assign to someone else without first talking to them. It's our 'hot hand off' rule.

                               

                              Thanks again.

                              • 12. Re: Incident Assignment Discussion
                                Anne Brock

                                Back to your original question - I can't speak to how many customers rely on the "assign to logged in user" feature when taking an incident; to me, it seems like a good thing to do to save the effort of having to assign ownership.

                                 

                                However, putting in an idea to have this configurable - maybe by queue - sounds good to me. Post that idea and I'll be happy to vote on it!