Blog Site Review – 89 Sites and counting!

As a citizen developer it is important to be in touch with the Salesforce community and to learn how others solve problems.  For me I have almost always been able to find the answer to my question either in the success community, developer forum or from a blog site.  In my quest for answers I have so far identified 89 Salesforce related blog sites and I find more every day.

I thought it might be helpful to you if I share what sites I have found so you too can benefit from them.  So I will begin a series of posts focusing on a different blog site.  I will provide (where I can) some basic statistics, an overview of the information found on the blog and key posts I have found helpful.

Basic Stats:

  • URL of the site
  • Primary owner of the site (person or company)
  • Date of first post
  • Total number of posts as of date of my summary
  • Post Categories/tags

I hope you will find this series helpful.  Let me know what you think.


Focus on ‘Why’ instead of ‘How’

Knowing the how is necessary.  Understanding the why is illuminating.

Knowing how to perform a task is necessary.  Understanding why the task needs to be done can help you achieve a deeper understanding of the task and the process to which it is related.why what how

Knowing how to implement a solution in Salesforce is necessary but understanding why the solution is needed is much more important and illuminating.   Many times users will ask for changes based on their perception of how to fix the problem.  These changes sometimes address the immediate need but not the underlying problem that created the issue in the first place.  By asking users why they need a specific change, the analyst can get to the heart of the problem and help find the best solution to address the underlying problem so the issue will not happen again.

According to a new study in the Journal of Consumer Research, people who become focused on how to achieve a goal may have a harder time achieving their aims than people who think abstractly about why they want to do something.


Can you share an example when knowing the ‘why’ helped with finding the best solution?


Good, Better, Best Requirements

I have gathered and documented thousands of requirements for hundreds of applications over
the years.  Good requirements are easily understood by the IT team and are testable.

I recently found a great post by David Shaffer called “It’s the clipboard2Requirements fault! A Recipe for Requirement Clarity “.  He really provides a clear concise method for developing solid requirements.  Below are a list of questions from his article that I highly recommend any analyst consider when gathering and documenting requirements.

For each requirement you ask the following questions:

  1. Is the requirement written in S-V-O format? (Subject-Verb-Object)
  2. Is the requirement written in active voice using a strong auxiliary verb?
  3. Does the requirement focus on the business need rather than a technical solution?
  4. Is the requirement easy to understand by all audiences?
  5. Is the requirement simple, short, and unambiguous?
  6. Will an example improve the understanding of the requirement?
  7. Will a visual figure or wireframe improve the understanding of the requirement?
  8. Can the requirement be tested?
  9. Does the requirement contradict any other requirement?
  10. Does the requirement describe how it must be implemented (Ex: display in alphabetic order, ascending/descending order, required/optional field, alphanumeric, numeric, etc.)


What are some questions you normally use when gathering requirements?

4 Types of Email Notifications

Emails are part of the business landscape so including them in your Salesforce applicationemail1 makes sense.  Designing the look of the email and its contents is important so that the emails provide users with the right information at the right time.

So what are some typical scenarios that result in email notifications?

  1. Acknowledgement – when a user submits a request, CASE, etc
  2. Status Update – providing user with status of request, CASE, etc
  3. Escalation – providing user with information on an escalation
  4. Information – providing user with information

Design Considerations for Salesforce Email Templates

Every email should include the following:

  • Reason person is receiving the email
  • ID / Link back to the Salesforce record which resulted in the notification (if appropriate)
  • Relevant information
  • Next Steps for person receiving the email (if any)
  • Next Steps for Company/Group (helps to set user expectations)
  • How to contact us

In the process of creating your templates consider the following:

  • Pick the appropriate email template type based on what your email recipients can handle and the level of layout control you require.
  • Maximize your subject line
    • Keep it concise but informative
    • For mobile recipients some researchers feel the first 35 characters are key
  • Use Merge Fields to personalize content
    • Be sure the merge fields you will be using have data. The merge field will not appear in the email for a record where there is no data in that field.
    • Email templates give you access only to the fields that are accessible to you via your page layout and field-level security settings.
  • Configure your email Deliverability Settings — Information about these settings can be found here.

A great place to see how to create a Salesforce Email Template is the article “How to create an email template in Salesforce” at


How do you use email notifications in your business?

Using Salesforce to Manage Users’ Requests – Part 2


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:metrics1

  • 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.

Input Channels

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.
Input Channels

  1. Face to Face
  2. Phone
  3. Instant Message / Chat
  4. Email
  5. Webpage
  6. Salesforce

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

Using CASE

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.

What Fields

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.

User Experienceusability1

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?

Data Quality

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.

Email Notifications

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:email1

  • Acknowledge Submission
  • Status Update
  • Escalation

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.

Simple Status Progression

Escalation Rules

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?



Using Salesforce to Manage Users’ Requests – Part 1

In order to manage users’ requests it is important to have a defined process where all requests are processed.  The steps needed to define and implement a process are:

  • Determine the what
    • type of user requests are to be handled in this processNowServing
    • key metrics will be tracked for this process
    • information for each request the user must supply
    • non-user supplied information is needed
  • Determine and implement the how
    • Input channels for submitting a request
    • Salesforce object to use (CASE or custom)
    • Fields (existing and new)
    • User Experience (Page Layout(s), Existing fields to use, etc)
    • Data Quality (validation rules)
    • Setup appropriate components within Salesforce
  • Determine communication
    • Reports and dashboards
    • Training
    • Release Communication

In part 1 of Using Salesforce to Manage Users’ Requests we will be addressing the “what”.

Type of User RequestsDM Gears1

Users may ask you for many things which can be grouped into the following general types:

  • Information: how do I do something, how does this work
  • Issue: can you fix my problem
  • Functional Need: I need system to do this

In your request management system you will need to decide if you want to handle all three types of requests through the same system.  In some organizations production problems (issues) may already be handled through a different application or process.  For this series of posts we will assume that our request management app will handle all three types.

Key Metrics

If you don’t measure your process, metrics1
you can’t manage or improve your process.

With every process and system you need to define your success criteria so you will know if what you created is meeting everyone’s needs and performing well.  You must therefore identify some key metrics upon which you will monitor and evaluate the request management process and app.  As you are considering what to measure remember that every metric should lead to a management decision.

Some suggestions are shown below.  The KPI Library is a great resource for ideas on metrics.

  • Time to Completion by request type

For each type of request define what an acceptable completion time will be and communication that to the users.

Example:  Information requests will be completed within 72 hours; Issues will be acknowledged within 1 hour and addressed within 24 hours; Functional change requests will be acknowledge within 4 hours, vetted within 3 days and completed within 2 weeks.

  • Hours to Complete by Request Type

For each type of request capture number of actual hours worked to complete it.  This information can be used in a metric called

  • Percent of requests by priority

This metric reflects the size of the potential risk of urgent changes on the quality and performance of the change management process.

User Supplied Informationclipboard2

What information should a user be required to provide when submitting a request.  The information will probably vary depending on the type of request.

For all requests I suggest gathering the following:

  • Requester’s full name and contact information (at least phone and email)
  • Type of request (Information, Production Issue, Functional Need)

Below is a suggested list of information based on request type:

  • Information
    • Question
    • Why do you need the information
  • Issue
    • Description of Issue
    • When did it occur
    • Name of application (if you are supporting several applications)
    • Attachments for screenshots
  • Functional Need
    • Name of application (if you are supporting several applications)
    • What business problem are you trying to solve?
    • Why does this problem need to be solved?
    • How many users are affected?
    • If there currently a workaround? If so, describe workaround.

Non-User Supplied Information

As requests are processed additional information is needed to support our key metrics as well as to manage the process.  This information would be supplied by someone other than the user.

Below are some suggested information:

  • When (date) was request submitted
  • What is the request’s priority
  • Who owns the request / who is working on the request
  • When (date/time) did a person start working on the request
  • When (date) did the request get completed
  • What is the status of the request
  • What was the answer (if request was Informational)
  • What was the solution (if request was production issue or functional need)
  • Who approved work on the request (If request was production issue or functional need AND your process requires approvals)

Stay tuned for the next part in this series where we will explore the “how”.

Questions for Youbusiness-man-question-mark1-300x282

Have you implemented a process to manage user requests?  If so, what types of requests do you track and what information do you capture?



Manage Business Hours Holidays

For this installment of my permission series we are going to review the Manage Business Hours Holidays permission.  Before we see what this permission allows a user to do, we first need to review Business Hours and Holidays as defined within a Salesforce organization.


Business HoursHoursOfOperation1

The hours when your support team is available to serve customers.

  • By default business hours are set 24 hours, seven days a week in the default time zone specified by your organization’s profile.
  • Several sets of business hours can be defined for an organization so that different service hours can be related to holidays, cases and other areas.
  • Salesforce automatically calculates daylight savings times for the time zones available for business hours
  • The Business Hours field cannot be included in list views or reports.
  • The Business Hours field can be added to CASE layouts to allow users to view and define a specific set of business hours to a case.
  • Business Hours on a case are automatically set to your organization’s default business hours unless an escalation rule associated with a different set of business hours is activated due to matching criteria
  • Escalation rules only run during the business hours with which they are associated
  • Business hours included in escalation rules must first be removed from these rules before being deactivated
  • Hierarchy of Business Hours:
    Business hours applied to a milestone override business hours applied to an entitlement process, which override business hours applied to a case. If no business hours are set on the milestone, then the Entitlement Process Business Hours are used. If neither the Milestone Business Hours nor the Entitlement Process Business Hours are set, then the business hours on the case are used.


Holidays let you specify the dates and times your customer support team is unavailable. After you create a holiday, you can associate it with business hours to suspend business hours and escalation rules during holiday dates and times.

  • Up to 1000 holidays can be associated with each set of business hours.
  • Holidays automatically acquire the time zone of the business hours with which they are associated.
  • You can only add business hours marked as Active to holidays.
  • Holiday names don’t need to be unique.
  • Report results do not take holidays into account.
  • A holiday can be set to recur on a specific day of every month (20th or first Monday, etc).

What Can You Do With This Permission?

A user with a profile or permission set having the Manage Business Hours Holidays enabled can do the following:

  • Define business hours
  • Edit business hours
  • Define holidays
  • Edit Holidays
  • Associate business hours to holidays

A user with the Customize Application permission enabled as well can also do the following:

  • Add Business Hours field to the Case Layout page
  • Associate business hours to milestones in entitlement process
  • Associate business hours with escalation rules
  • Associate business hours with entitle processes


Guidelines for Setting Business Hours
Set Business Hours
Setup Support Holidays
Guidelines for Creating Support Holidays

What is a citizen developer?

The division between IT and business is blurring and organizations are seeing the rise of a new type of employee – the citizen developer.

A citizen developer is a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT. In the past, end-user application development has typically been limited to single-user or workgroup solutions built with tools like Microsoft Excel and Access. However, today, end users can build departmental, enterprise and even public applications using shared services, fourth-generation language (4GL)-style development platforms and cloud computing services such as Salesforce.1

Why have citizen development?

IT Departments are understaffed as business makes greater demands – with more work than they can handle due to inadequate resources and funding so IT focuses on the most critical business needs and allowing others to fall to the bottom of the pile.  Unfortunately those items at the bottom may never see the light of day.  Citizen developers have stepped in to fill this gap.  Use of low-code platforms such as Salesforce have improved operational efficiency, reduced time to market and increased employee productivity.[4]

DIY by SME’s vs. IT’s ability to capture requirements and execute solutions[2] – In some cases a technology solution can be easier to implement and be more on the mark if done by a citizen developer that has deep subject matter expertise on the business and issues being addressed.

Reduced Maintenance Costs for No/Low Code solutions – It can be quite costly to develop custom applications using code.  Usually the development team that creates the application doesn’t stay to maintain it and funding for ongoing maintenance usually dries up.  Citizen developed applications are largely no or low code solutions deployed on SaaS or PaaS platforms.  Such applications usually require less maintenance and can be easily enhanced.[2]

Tech savvy business users are here!  More technically savvy individuals are entering organizations in non-technology functions.  These individuals are interested in taking on more of a technical role.  Given the right platforms, processes and governance these users can become citizen developers.[2]

What’s the risk?

Citizen developers are concerned with solving an immediate problem.  This focus results in a solution that helps business with its issue but may also not fit well into the overall IT ecosystem.[2]

Important parts of the complete development picture are sometimes not considered or defined by citizen developers:[6]

  • Who will support the application?
  • What other tools and applications will need to integrate with the application?
  • If there are bugs or problems, what will the wider impact be?

Making it work

“If citizen development is done properly in partnership with the IT department, then that can work, “ says Mark Driver, a research director at Gartner.  “There is a distinction between people who develop unbeknownst to IT – we call that shadow IT – and citizen developers who work in partnership with IT.”[5]

IT departments will need to evolve to support the rise of citizen development in a way to minimize risk to the organization.  IT provide citizen developers with approved or sanctioned SaaS or PaaS platforms, set security policies, define best practices and take on the role of guardian and mentor to citizen developers.[6]

1: – Citizen Developer definition
2: 4 Reasons Why Citizen Developers May Be the Next Big Thing in Application Development
3: The Advent of the Citizen Developer (graphic)
4: ‘Citizen developers’ are ready to fill the gaps in enterprise applications
5: Can citizen developers bring shadow IT into the light?
6: Citizen Developers will ruin software discuss