12 Replies Latest reply on May 5, 2016 9:37 AM by Mikko Lehtola

    Renaming fields

    Hans Eisenman

      What happens if we want to rename a field in our Incident form?


      For example, we have one called Urgency. (It may or may not be a system/default field--I don't remember at this point.)


      In any case, there are three values in the dropdown and I'd like to rename a couple of them.  Is that even possible? If not, how can I make adjustments to that field's values?


      There is some logic between that one and another field (Impact) which, together, calculates Priority (1-5 depending on which of those two are selected in any given ticket).


      What I don't like is that "Low" priority says "1 week +" next to it. I don't want to have that sort of expectation "hard-coded" into that priority


      There's another field which is in a selection box which opens up. They are the subcategories. I'd like to rename a couple of these too but my fellow admin thinks this probably has to be done by deleting the old name and making a new one altogether. Is that right?


        • 1. Re: Renaming fields
          kedar zavar

          Do not delete categories - deactivate them or rename if you want to re-purpose . This way you do not break reporting or workflows etc.

          You an rename impact and urgency but it would change value for over all RF


          Navigating the Remedyforce Administration tab - BMC Remedyforce 20.15.03 - BMC Documentation

          You can also use tools like data loader.


          1 of 1 people found this helpful
          • 2. Re: Renaming fields
            Mikko Lehtola

            Problem with Impact and Urgency fields is that they are so generic, they do not tell really anything (for custoemrs or IT). Also in different services they may have different meaning - sometimes even different list of values (e.g. CRITICAL is understandable for some application service but not for master data service). Also looks like the out of the box fields are thougth mostly for 1st level, not for 2nd or 3rd levels - especially standard relation to Due date is too simple


            My two cents:

            - Use on request forms terminology which opens up the value is customer understandable form (like: Users affected: Some on site (Low), Whole site (MEDIUM) Globally (HIGH))

            - Wa have a custom "Priority" (formula base on urgency/impact) field, which shows the priority for IT staff in little more understandable terms. Also this field we have taken to console view & emails. So standard field cannot be changed, but it can be replaced with a better one...

            Here you want to control your enthusiasm since if a request gets routed between different teams your logic may become short. Also if you are having SLA's defined you need to think the relation to Priority if the priority changes during request life cycle.

            1 of 1 people found this helpful
            • 3. Re: Renaming fields
              Paul Donders

              You might want to look here: Business Importance Level | Remedyforce


              What I don't understand; why a different set of Priority for the agents? Let's keep it simple, the ootb priority and due date. Those, or others, can be used in SLA's and that will give you the response and resolution time. The Due date progress icon, or a custom icon, will give you a direct insight how you are performing related to your sla.



              Best to describe Impact:

              • None - No Degradation of Service
              • Low - Service Degraded for 1 User
              • Medium - Service Down for 1 User or Degraded for Several
              • High - Service Down for Several Users
              • Major Incident
              • 4. Re: Renaming fields
                Mikko Lehtola

                I think we are actually very aligned here - you probably have been thinking a bit more.

                -  I like this idea of usign service kind of "weighting" the request - I kind of tried to say more or less the same thing: CRITICAL is not a valid option for all the services

                - however "IT Staff" is not a 100% harmonized group. Depending on your role (L1, L2, L3), the expectations on how fast you react are on different levels - at least with us. Still the same set of categories could be used, but they concrete (visual) meaning could be different. Using tasks is kind of one way out of this (separating customer and IT teams priority)

                - I see this also valid for Service Requests - not only incidents. Master data fault at end of the month when closing the books deserves higher priority than some others.

                - Making things concrete is the problem - like you have added the descriptions. That you cannot really do with oob RF, so some sort of customization is required. And you have added the last category (what we have done as well)


                Then just cultural things:

                Our IT people were taught on legacy systems to only on "priority" field. now having Impact & Urgency is considered more difficult and not concrete - so some communication and organizational change management would be neeeded.

                Also when you are talking with your partners, your Servicedesk, expert teams and thinking about the customer promise everyone has own expectations on what is "High" priority - always in discussions you should define meanings of the priorities, before you go too deep... Legal contracts bring in another can of worms.

                • 5. Re: Renaming fields
                  Paul Donders

                  Please check this idea as well;

                  Service and CI relationship

                  • 6. Re: Renaming fields
                    Hans Eisenman

                    These are all great responses.


                    If you'll humor me, I'd like to offer you a bit more background and then see what you think about a possible approach to resolution. Sorry in advance for the length. I'll try and keep it as quick a read as I can.


                    Right now, we have two main groups using the same incident form and I think that might be some of the problem when it comes to things like Impact and Urgency and thus Priority.


                    On the one hand we have the IT department which handles all the hardware, networking, servers, etc.


                    On the other, my group, we have DevOps where we are responding to purely software issues (1,000 seat call center with "home grown" software managing calls, etc.).  That is my main concern here in this post.


                    Our software incidents break down into the following categories or types (shown in order of their typical resolution priority):


                    • Bugs
                    • Launches (work needed for new clients)
                    • Level of Effort Estimates (for new work)
                    • Feature requests


                    We have, until RF released in our area, been using a Smartsheet (online, highly flexible, feature-rich spreadsheet product which greatly facilitates collaboration of any kind of work).


                    Sidenote: I've been using this as a kind of user interface proxy, if you will, to our old ticketing system because it allowed me to quickly dial in the data elements we needed to manage the work effectively for our internal customers. Existing ticket system (Request Tracker) was too inflexible in the priority setting department. The added bonus was I learned a lot more about the work and needs around it because I got our customer heavily involved, allowing them to work directly with the data elements.


                    Looks like this:

                    smartsheet 2016-04-28_11-21-57.jpg


                    50% of our ticket flow comes from one of our 5 main companies which we support (we'll call them "SVC"). The rest are evenly scattered over the other groups and are not usually as high priority.


                    So the "Smartsheet" we have been using allowed for us to quickly adjust priorities because our customer (3 Account Managers in SVC) could literally just put a 1 or 2 or 3, etc., next to the incident to set priority.


                    In other words the Account Managers could have quite a bit of say in which of their tickets we would handle first, since they knew better than anyone what their client needed.


                    I'm trying to figure out the best way to keep prioritization simple and informative to our customers in all groups using RF.


                    But since SVC is our biggest customer, I am catering to them a bit.


                    I'm thinking this might mean creating a separate incident form for DevOps incidents and then the question I'm grappling with is what the best way would be to rig up this Priority vs Task vs Urgency relationship.


                    (i'm not quite up to SLA management yet, but I want to get there at some point. It's still a mad rush to get all the tasks done and that nuance is just not quite available to me yet-mentally.)


                    In real life (all tools aside), our priorities are set by the following factors either singly or in some combo:


                    1. Type of incident (as per above...bug, etc.). Bugs are usually top priority.
                    2. Sense of Urgency (High, Med, Low). Often this is just a "best guess" by Account Managers or us
                    3. Sometimes there's a hard date deadline, often not


                    So a Bug might be low or it might be high. If our customer's client is squawking it's going to be likely be high.


                    Or a Launch will often have a due date of xx/xx/xx. So that's kind of forcing a higher priority.


                    Or, it's a feature that's of Medium urgency based on what the Acct Manager feels is most appropriate..


                    Or some other combo.


                    One other vital factor: priorities change--without warning sometimes. So it has to be easy to take an incident and move it from a 3 priority to 1. But I don't want to tinker with dropdowns in that incident until I find the right combo. Have to able to override it and say "these tickets here are 1, 2 and 3 priority today..."


                    With that info, and knowing the constraints and capabilities of RF way better than I do, I'd love to hear any suggestions you fine folks may have for how to best approach this.


                    Thanks in advance. I'm enjoying the responsiveness of this community and hope to give back to it more as soon as I'm able to offer some value of my own.

                    • 7. Re: Renaming fields
                      Paul Donders

                      Ok, so in summary two teams with different needs..


                      Sounds to me like they are all or the most from type incident (or bug as you can them) but based on condition an other Resolution time.


                      So if you ask me it all comes down to SLA's. Example; Customer 1 with prio 2 means 4 hours, while customer 2 with prio 2 is 2 hours.


                      Its not impact x urgency = priority = due date, but more like account + service + priority = due date.


                      Please investigate the sla part, that is my advise. No need for different forms and over customizing the forms.

                      1 of 1 people found this helpful
                      • 8. Re: Renaming fields
                        Hans Eisenman

                        Thanks for taking the time to read my short novel.


                        i'll have to review the SLA documentation in RF as it is a new area for me.

                        • 9. Re: Renaming fields
                          Jonathan Leighton

                          Hi Hans,


                          Looks like you've had some great feedback on this topic already.


                          We have a couple of overview videos on SLM in our Enablement Kits page which you may find helpful -> Remedyforce Enablement Kits


                          Best Regards



                          • 10. Re: Renaming fields
                            Mikko Lehtola

                            You have not mentioned how visible priorities are to the customers. What comes to following / keeping customer promises I would definitely use SLA calculation for that. Due date you can forget - it is oversimplified. Very few things are perfect and SLA calculation may not work 100% the way you wish when changing priorities - but I would use that to customer side. Here Paul already gave some good tips.


                            What then comes managing "internal" work queue - SLA's could be used for that as well, but I think they are not too visual on request and little complicated. Moreover I am not sure if you even can use these on the console view to order requests. For this I would add a picklist or two (e.g. Customers view on things and your Account manager view/feeling on priority) on and then make a custom calculated "Priority" (ticket type could also be a factor). Also this way you can have your own understandable terms used. Paul is correct there that then you probably would like to hide the standard fields and use your custom ones - also on emails if you send those to customers/staff and console views.  But if this is a significant thing for your business I would customize this.


                            Hard deadlines I would not try to automate to raise priority - This I would just have a date field and separate view. But these are just my opinions...

                            • 11. Re: Renaming fields
                              Hans Eisenman

                              Thanks for your input.


                              How would you deal with, for example, a hard launch date that has to be met for a client?


                              Maybe you described this but I'm sitll not clear on it.


                              The calculated nature of the current Priority field makes it difficult to manage when it comes to something like a hard date.

                              • 12. Re: Renaming fields
                                Mikko Lehtola

                                Well... The hard launch date closing in does not mean that anyone would be saving the SR => transaction based priority recalculations would not work. You would need a time based flow (running every hour or something like that). This should be doable as well - only I have not made such things.


                                Actually SLA may send notifications if you have certain hours or % of total time left - but I would not know how to program a hard deadline into a SLA.


                                I would simply have a custom field on the incident for hard deadline:

                                - Very easy to see and understand, if deadline changes easy to change ( I would follow the the field in hostory to "audit" changes

                                - Can be easily used on reports, views (console & SFDC) and emails

                                - Could have indicators programmed ("Did we make it or not")

                                - You could create another field - "Time to deadline". Calculating "dead-line" - NOW() as hours - this way you certainly can order things.. When this is on minus side... you know.. This field I would not put to display.


                                Then would take this to console and create a view for open requests where dead-line is not empty. Even better would be to make a Remedyforce dashboard to show on the same go hard deadline items and "priority based" items. I have not played around too much with these reports but there you could have more graphical presentation  (maybe even create a color coding for those items where dead-line is closer than X hours).


                                Sidenote: deadline ahould also have time - if working over multiple timezones date is just not enough.

                                1 of 1 people found this helpful