Share This:

Hopefully you are starting to feel Remedyforce knowledgeable now that you’ve taken the Remedyforce online training recommended in Week One! The beauty of the web-based training courses is that they are self-paced, so keep going the second week if you haven’t finished up all the courses that you wanted to take. From an enablement perspective you also should have had your “Welcome to Remedyforce” meeting with your Business Relationship Manager. So now what?


Well, let's talk about beyond week one!  It is important to keep in mind that the information in is this blog is very high level and intended for a broad audience as helpful enablement resource. If you’re an organization engaging/engaged with our Remedyforce Onboarding Team or Partner Services Teams, you may have scoped an engagement that gets you into production on a very different timeline using a proven methodology.  However, if you are not using any implementation services, perhaps this information is a good guide for you to help with your planning and phasing so you get an idea of what to expect.


Most customers begin with Incident Management which is a logical choice. But before we jump right into the incident management form, fields, and functionality, it’s important to talk about “Foundation Data”.


Foundation Data in Remedyforce is comprised of elements that touch all the separate ITSM areas inside of Remedyforce and provides a unifying element to the configuration. In other words foundation data is the building blocks to get Remedyforce off the ground and production ready and at the core, foundation allows for the categorization of incident and self-service records which allows for more efficient routing and data mining to build reports and extract Critical Success Factors and Key Performance Indicators.

By the way, if you are a Remedyforce customer with Summer15, you will have access to a lot of OOTB content already that was pre-configured by our Remedyforce Onboarding team that includes some smart practice suggestions for Foundation Data and other areas. The smart practices content contains a lot of what you will need to deploy Remedyforce as a turnkey solution. So now let’s take a look at some of this foundation data that you will need to discuss as a team and make decisions on for solution configuration: Categories, Impact/Urgency, Priority and Queues.


Agreeing on categories for incidents and service requests tend to generate a lot of excitement (and colorful discussions) within organizations. Changing Service Management solutions is a very good time to re-evaluate what is working and not working with regard to your categories. What you don’t want to do is blindly port over your existing categories without assessing the value of them or if you all agree that they are still fit for purpose. Something important to remember about categories is their purpose. Categories should be designed to route your incidents through the lifecycle as well as being used in reporting and as inputs to other processes such as problem and change management.


Don’t know how to get started with categories? Check out this snapshot from the smart practices content from Remedyforce Onboarding team as well as this great white paper developed by our onboarding team on categories.


Sample Categories.png

At a high level, Categories allow you to create classifications for the tickets that you want to group or track for reporting purposes. You can organize your tickets/data by using category types and defining parent and child relationships between categories. Categories go across all types of tickets; Incidents, Service Requests, Problems & Changes. When all else fails – don’t overcomplicate your categories!


Now let’s talk about Impact & Urgency and Priority foundation data. Impact and Urgency helps determine in what order incidents will be addressed. Since Incident Management Process escalation rules are usually based on priorities, assigning the correct priority to an Incident is essential for triggering the appropriate Incident escalations.


An Incident’s priority is determined by assessing its impact and urgency, where:

  • Urgency is a of measure how quickly a resolution of the Incident is required
  • Impact is a measure of the extent of the Incident and of the potential damage caused by the Incident before it can be resolved.


Urgency & Impact and Categorization of course are key factors in helping with a number of functions including assignment and reporting. I recommend you take some time to review your urgency and impact matrix. Include specifics for impact and urgency escalation guidelines to help the team understand their responsibility.



Priorities determine how incidents will be handled by support teams helping them to prioritize their workloads. Some smart practices for workload prioritization include:

  • Focusing on the high priority tickets (remember your impact/urgency matrix color scheme)
  • Focusing on the due date – first in / first out concept
  • Look at the description to get the details of the incident
  • Upon review of your assigned incident, choose a path:
    • First call resolution - Can I resolve this incident myself?
    • Do I need to escalate to the next level?
    • Do I need to contact the user for additional information?

Priorities also drive Service Level Agreements (SLAs). Be prepared to start discussions around SLAs for P1 incidents, and P2 – P4 type incidents. Typically you’ll want to begin with Response times and Resolution times. For some good practice guidance, check out this blog and video series around SLAs by another Business Relationship Manager!


Speaking of support groups and escalations, another important area for foundation data are your Queues. Queues are pretty self-explanatory. They are the groups that you want to be able to assign incidents to. You will also be assigning members to these queues. But it’s definitely something you will want to discuss as part of the incident lifecycle and your design of SLAs. Whatever can’t be resolved at first contact by your Service Desk, you’ll want to ensure there is an easy way to route those incidents to the next levels – are you starting to see the link between categories and queues?


Here’s a look at some examples of common queues from our Onboarding team’ smart practices:


Sample Queues.png

Good tip – you’ll notice there is good alignment to the categories seen in the previous screenshot!


Hopefully you’re building a picture here for understanding how foundation data is really the place to start since this is the data needed to start creating basic tickets. We then need to categorize the data which has 2 purposes remember: Routing and Reporting. What you are doing today can help determine your foundation data. Example do you want to create tickets based on email? Phone? Self-Service Portal? Chatter and Chat? What are the common top 10 received at Helpdesk and how are you going to display those?


So once this has been established you can transition nicely to looking at the Incident Management incident form to determine what fields are necessary to capture information for your Incident Management Process.


Part 2 of this blog in the “Welcome To Remedyforce” series will dive into Incident Management and include some guidance about smart practices for incident management and beyond.


As always, the Remedyforce team welcomes your feedback. If you have questions or have suggestions add them to the comments section below.