In order to manage users’ requests it is important to have a defined process where all requests are handles. The steps needed to define and implement a process are:
- Determine the what
- Determine and implement the how
- Input channels for submitting a request
- Salesforce object to use (CASE or custom)
- Fields (existing and new)
- Usability (Page Layout(s), Existing fields to use, etc)
- Data Quality (validation rules)
- Setup appropriate components within Salesforce
- Determine communication
In Setting up a Request Management App – Part 1 we addressed the “what”. In this post we will be addressing the how at a very high level except for the setup which will be covered in Part 3. Additional posts will provide a deeper dive into some of the areas.
As part of designing your request management process and application it is important to understand how you expect users to submit their requests into the system. A user can use any or all of the following channels to make a request for information, report an issue or request an enhancement.
- Face to Face
- Instant Message / Chat
For input channels 1,2 and 3 the Salesforce Administrator will be the one creating the request in the system. For input channels 4, 5 and 6 the user will be creating the request in the system.
Through continued training and good feedback and status information for requests you could reduce or perhaps eliminate input channels 1 – 3 so that the Salesforce Administrator is not manually creating requests.
Which Salesforce Object to use?
The design decision around what Salesforce object to use as the center component of the request management application can be affected by several things
- what version of Salesforce your company uses
- how deeply you are currently using CASE
- do you have resources with the skillset to do customizations
The ideal design option in my opinion is to use the CASE object. It provides inherent functionality to allow users to email or submit a request via a webpage and have a case automatically created.
Use Custom Object
If you feel that the risk of using CASE for request management is too great due to how your organization is currently using this object, consider creating a custom object instead. With this option you will have to handle functionality related to processing emails and requests submitted via a webpage yourself.
Regardless of which option you choose, CASE or Custom Object, you will need to design the fields to be created on the object. In Setting up a Request Management App – Part 1 we defined a number of pieces of information that we would need to acquire at the beginning or during the request management process.
Here are some things to consider when creating fields:
- Make the field name meaningful and concise as possible
- Use the appropriate datatype
- Include a description FOR EVERY FIELD!!! (See Mike Gill’s post Admin Commandment 1 for more information as to why this is important)
- Include help text as often as possible. Make sure it is written with the user in mind.
The area of User Experience (UX) encompasses many components and too involved to go into in this post; therefore, we will focus on just usability.
A solution to a problem can be achieved in many ways. Some ways are efficient but are not very usable to the people who will be actually using it. As Citizen Developers we have a great advantage on designing for usability because in many cases we will be using what we are designing!
So what to consider with regards to usability?
- Is information grouped together and labeled in a way that will make sense to the users?
- How many clicks does it take to do common functions or to access common information?
- Is the help text actually helpful to the users?
- Are the messages displayed to users (error, informational) useful and provide enough detail for users?
- How easy is it to use the solution?
- How quickly can users perform tasks?
The old adage of “Trash in is trash out” applies to data. Bad data in from imports, data load process and other sources results in bad data out in reports or down the line to downstream processes. So how can Salesforce Citizen Developers achieve high quality data when designing a solution?
- Understand the data that is going to be loaded and how the data will be mapped into your solution
- Create alerts to notify key users of any data quality issues
- Stop bad data from being entered using validation rules and required/read only flag on page layouts as needed
- Create and distribute reports and dashboards specifically focused on data quality
Other Design Decisions
There are so many decisions to be made when designing a request management process it can be overwhelming. One method to make sure you hit all the important items is to walk through the process on paper or whiteboard. “Wear” the different hats (user, citizen developer, manager, etc) to be sure all the information each needs is defined and the process (statuses) make sense.
Emails are sent for a variety of reasons. As part of the design you will need to determine when you want to send out an email, to whom will it be sent and what will it say. Some possible scenarios are:
- Acknowledge Submission
- Status Update
Support Process (Status Progression)
Where a request is within the support process is usually indicated by its status. What statuses to use, what each means and how a request moves between them is important.
A very simple status progression is shown below. Request comes in with status of NEW. As it is being worked its status is IN PROGRESS. When it is completed the status is COMPLETED. During the process the request could be cancelled.
For each type of tracked request we have a defined an expected completion time which feeds into our key metrics and which also has been agreed upon by the users. Escalation rules are there to make sure every request is worked within the expected timeframe.
How will escalation process be handled within the request management system?
- What criteria will be used to determine escalation?
- To whom will escalation notifications be sent?
- Will ownership of escalated requests be changed? If so, how?
- Will requester be notified of the escalation?
- What are the ramifications for an escalated request?
Email to CASE / Web to CASE
Input channel of email or web form requires some design work.
- Email to Case Routing setup (priority, origin, create a task)
- Web Form (where will this form be put?)
Questions for You
What are some design tips not covered in this post that would help Salesforce Citizen Developers create a request management application?