What to Consider When Designing a Case Management System

A multi-million dollar enterprise case management tool has consumed the past few months of my work life. Along with a team of front and backend developers, business analysts, scrum masters, and project leads two unique solutions have emerged: a Salesforce Community for customers and a Salesforce Service Console for those working the cases. As the projects progressed, I found myself saying, “Well, next time we’ll know to…” or “I wish I would have…” And so I began to document my lessons learned as we progressed through sprints.

In tandem with the first case management project, I’ve started working on a second case management project for a different client to improve efficiency of service and support for HR. Already, we’re tackling the project initiation in a very different way – a user story map was created during discovery instead of a month of demos of the current system from the first project client. Below is a checklist of items I’ve learned to look at, particularly for service design in Salesforce. It is ever growing and would benefit from any additions you have.

Community design

  • What are the needs? Try to keep the client, SMEs, stakeholders, etc. from the phrase “I’m envisioning a dropdown with different choices for _.” Instead of writing that vision down as a requirement try summarizing the need you hear from what they say (e.g. “so it sounds like you need to be able to _. Why is that?”)
  • Gather styles for header, footer, links, list views, navigation
  • What will be your default sort on list views?
  • Review style standards early on
  • Review interaction standards early on
  • Does this need to be responsive? (#duh)
  • Decide case type (camel versus sentence). Sentence case in Salesforce can be very challenging.
  • Dropdown default value (none, please select)
  • Field label rules (e.g. Colon at the end? Question mark after field labels posed as a question?)

Console design

  • What related lists/tables should exist on page details? Is consistency important?
  • Interaction of tabs and subtabs (pretty specific to Salesforce Service Console – one of my least favorite native functionalities in terms of usability)
  • Trust your gut. If something isn’t usable, if the project is mismanaging UX efforts let your PL know and move forward as you see fit. It’s terrible creating a solution you could’ve improved upon simply by speaking up
  • How will statuses and routing automation be handled?


  • Review constantly and don’t be afraid to create bugs and improvements – cover your butt for when the PO or client says something is wrong (then you can just tell them it’s logged and they need to prioritize)
    • Empowers PO to prioritize with some added ease because they don’t have to find these updates AND prioritize
  • Have a source of truth for Acceptance Criteria for a particular process. Identify a way to tie bugs and improvements. (Had a BA way of documenting – spreadsheet, UX way of doing – stories, etc). Consider using “related to” feature in Jira
  • Stakeholders do not know processes or needs as intimately as active users
  • Schedule usability testing early and often. It’s the best way to make design decisions and stop long guesstimating “I think users would prefer this” conversations
  • What metrics are users measured on (SLA will likely be involved. Consider how incentives and metrics affect your design)
  • Information Architecture/Categorization is not a group activity
    • Need a way to manage categories