Remedyforce Community Blog

Reporting on multi-level categories

Posted by on Jun 21, 2018 in RF | Comments Off on Reporting on multi-level categories

BY ANNE BROCK, RIGHTSTAR SYSTEMS

First, I want to define the problem we need to solve.

We had a customer who had a multi-level category tree- more than two levels. Some of her categories were three levels deep, some four, some five. Something like this:

 

Now of course, this isn’t a problem to set up in Remedyforce; you can have many levels, although we recommend not going too deep.

But the problem came with reporting: The customer wanted to run a report from the top level – in the example above, regardless of whether they picked Level 1, 2, 3 or 4, she wanted to run a report of all “Level 1” tickets. Since the ultimate parent category isn’t stored on the ticket, this took a little bit of work.

Now you can put the whole parent tree on the ticket – In the case of the above example, if I choose Level 4, that gives me a field with this in it:

 

If I pick Level 3, the field looks like this:

 

Which is a great start; but HOW do you pull the top category off of that? It’s on the right-hand side of the field – but of course, number of characters may vary. And you can’t just search for “>” because that may be in the string multiple times. Here’s what I did.

Step 1

Put a special character that the beginning of your top level categories. The sharp-eyed among you will have noticed I’m using an exclamation point.

 

Step 2

Put the Parent Tree on to your form. You can show it or not in the Field Sets; but create a field that looks up the full Parent Tree in your Incident form. So go to Setup/Create/Objects/Incident Object; and go to Custom Fields and Relationships, and create a new field. I called mine AB_Category_Tree. Create it as a formula field, and in the Formula, enter:

BMCServiceDesk__FKCategory__r.BMCServiceDesk__parentTree__c

 

I put it on my Remedyforce Incident form, so I could see the results:

 

Step 3

Create a field that will extract everything after the “!” and put it into a field that can be used for reporting. The important thing here is that IF someone chooses the very top level category – i.e. !Level 1 – the field we created in Step 2 will be blank, so we need to account for that.

So again, go to Setup/Create/Object/Incident and go to Custom Fields and Relationships. Create a formula field; I called my field Parent Category. This time, the Formula is:

IF( ISBLANK(AB_Category_Tree__c),   BMCServiceDesk__Category_ID__c , RIGHT(AB_Category_Tree__c, LEN(AB_Category_Tree__c)- FIND(“!”,  AB_Category_Tree__c) + 1) )

To break that down:

IF( ISBLANK(AB_Category_Tree__c),   BMCServiceDesk__Category_ID__c , This is for those cases where someone picks the top level category; since the tree will be blank, we’ll just assign the category
RIGHT(AB_Category_Tree__c We want to start from the right of the parent tree field, not the left and take a certain number of characters
FIND(“!”,  AB_Category_Tree__c) This gives us the place in the string where the special character is – I used !, but replace that with your special character
LEN(AB_Category_Tree__c)- FIND(“!”,  AB_Category_Tree__c) + 1) If I take the full length of the string (let’s say 25) and remove where I found the special character (let’s say position 17) I’ll have the number of characters remaining after the special character – 8. I add 1 back on to get the special character. (I’ll need this to match what happens if I just select the top level category.)
RIGHT(AB_Category_Tree__c, LEN(AB_Category_Tree__c)- FIND(“!”,  AB_Category_Tree__c) + 1) Using the example right above, if the string is 25 characters long and the special character is in position 17, I am taking the right-most 9 characters to fill in the Parent Category field.

 

Step 4

Create a report showing Parent Category and Category to see the results! No matter which category they pick under !Level 1, I can still report on all tickets that came in for that parent category.

 

And here’s that same report in Lightning:

 

Let us know if you have any questions or comments!

Dependent Picklists in Self-Service

Posted by on Jun 11, 2018 in RF, Uncategorized | Comments Off on Dependent Picklists in Self-Service

BY ANNE BROCK, RIGHTSTAR

In Winter, 2018, one new feature was being able to use Dependent Picklists in Self-Service. For me, it was a bit of a head-scratcher to figure out how to do it, so I thought I’d write it up.

First, let’s look at the end result. When you put a dependent picklist into incident self-service (“Submit a Ticket”), you get a field B that depends on field A. So below, if I choose San Francisco as my location, I get one set of drop-downs in the department field; if I choose New York, I get a different set:

 

 

You can do a similar setup for Service Requests. Before we look at how that is done, I want to address a couple common questions:

  • Don’t we have conditional questions on Service Requests anyway? Yes – absolutely. And I recommend continuing to use them because of the answer to the next question. But this feature is using Salesforce Dependent Fields functionality; and it does give us a dependent set of questions on the “Submit a Ticket” form.
  • Can I use different Dependent Fields on different Service Requests? NO – when you add Dependent Fields to your Request form, they will appear on every single service request. So unless there is something you want people to answer on every service request, keep using conditionals.

Ok, let’s set this up.

First thing is you might want to read up on Dependent Fields on the Salesforce site: https://help.salesforce.com/articleView?id=fields_defining_field_dependencies.htm&type=5

Next, check your setting in Remedyforce Administration/Configure Self Service/Service Requests. Uncheck the box by “Use the fields from Service Request Right Panel and Left Panel field set instead of Request Details Self Service 3.0 in Self Service 3.0” (if you will be using this for Service Requests).

 

Create your fields. Below, I’ve created Location and Department at Location, both as picklists, on my Incident Object (if you are doing this for Service Requests, add them to the Request Detail object):

 

Then create the Dependency – click this button at the top of the Custom fields list:

 

Click on New, choose your controlling and dependent field (in my case, these are Location and Department at Location), and get to this screen:

Highlight the appropriate values for each column, and “include” or “exclude” as needed and then Save.

 

Final step: you need to add them to the appropriate field set. For the Incident object, it’s “Self Service – Ticket Layout”; for Request Detail object, it’s “Request Details Self Service 3.0”. Below is my Self Service-Ticket Layout field set:

 

And now they will be visible on the “Submit a Ticket” form (where we started this writeup).

I would be very interested in your use cases for this feature; I was drawing a bit of a blank, but I’m not out in the “real world”, so let me know what you use this for!

Different Task Layouts for Tasks Created from a Change vs an Incident

Posted by on May 15, 2018 in RF, Uncategorized | Comments Off on Different Task Layouts for Tasks Created from a Change vs an Incident

BY ANNE BROCK, RIGHTSTAR

We recently had a customer request to have different task layouts, based on whether a task was created from an Incident Record or a Change Record. While we did attempt to talk them out of it, this is possible with the Layout Type functionality introduced in Winter, 2018. Here’s a way to do it. The instructions are a bit abbreviated due to the number of areas we hit, but hopefully you can follow along.

Step 1

Create two task layout types in Remedyforce Administration/Application Settings/Consoles. Make sure they are assigned to all the appropriate profiles. In my case, I decided to use the default layout for incidents, and created another layout for change:

 

You can see I have a field set called “Change Details” in the Task Change layout:

 

 

Step 2

Create a couple tasks, using the new layouts. You need this to get the ID of the layout in the next step.

 

Step 3

Use data loader to export your tasks. Now, you can just export all the fields and tasks, but if you want to get just the key fields and key records, use a qualification like this:

Select Name, BMCServiceDesk__RF_FKLayout__c FROM BMCServiceDesk__Task__c WHERE BMCServiceDesk__RF_FKLayout__c != ”

You can build that in data loader, but it’s not much fun finding the FKLayout field, so you may just want to copy and paste it.

That’s going to give you a file with two columns; column one is the number of the Task ID and column 2 is the ID of the Layout page. You just need to figure out which task was created from an incident, and which was created from a change; then you will have the correct ID for each layout type. In my case, task 1212 was created from a Change; so I know the ID ending in LAAQ is my Task Change layout; and the one ending in 33AAC is my Default task layout.

 

 

 

 

Step 4

You can now create either a workflow rule OR a process builder flow to set the Layout Type whenever a task is created from an incident or a change. I tried both; let’s look at the workflow rule first. (Of course, if you do both, you only want one to be active at a time.)

I first created a template, where I set the Layout Type to the Task Change type, and then did this workflow rule:

 

That’s pretty simple; but we know we want to use Process Builder more, so let’s look at that process. This isn’t the easiest to see in screen prints, but let’s walk through it. My first Criteria was Is it from a change? I check this by looking at the BMCServiceDesk__FK_Change__c field, and seeing if it’s blank (global constant Null).

 

 

If it is, I set the Layout Type field to the ID that I got through my export.

 

 

 

I then check to see if it’s from an Incident record, and then set the Layout Type field to that ID from the exported file.

 

 

 

Of course, if it’s coming from neither of them – I created it manually as a standalone task – the layout won’t be set by the workflow; it will then go to the default layout and I can choose a different layout if I want.

To test, go to an Incident (or a Change); go to the Details; and create a task linked to the Incident (or the Change). It should come up with the preferred Layout Type.

I’m sure a lot of you are thinking of different ways to use this – maybe based on the Category of the task, it gets a different default layout, or some other combination of factors – but Winter, 18 makes this possible.

Warning: If you are creating tasks through Service Request Management, you may want to choose the template there rather than letting this workflow drive it, so just bear that in mind – you may need some other kind of flag so this workflow doesn’t fire if it’s from self-service.

We hope this was useful!

 

Show Buttons
Hide Buttons