9 Example Admin Interview Questions

I mentioned in my last post (How to Interview A Salesforce Admin) the approach I like to take for interviewing Salesforce Administrators. That approach really helps to find out both whether the admin knows about the different tools available, how to use them, and the flexibility of their solutioning.

This post describes a handful of questions that fit in with that simple question design, and then I’ve gone through as well and given my explanation for the kinds of responses I look for in the interview process.

1. The business would like to stop users from selecting an Opportunity Closed Date which is in the future.

  1. How would you accomplish this?
    • The answer you should expect here is the use of a Validation Rule. That’s the In-the-box answer, and would be the most reasonable solution to this request.
  2. Are there any other ways to accomplish this?
    • Technically this can also be done via Apex, or in some cases, businesses will have a status field which explains any data integrity issues.
    • Don’t put a lot of weight on this one, as there’s really only the one common solution for this problem. If you get one of these answers instead of Validation Rules, this might be of concern, as this isn’t a typical Administrator answer, nor is it the accepted way to do this check. Apex validation is typically used for much more complex validation that this problem requires.
  3. Are there any other changes that might need to be made along with this change?
    • Odds are if a sales team was allowed to put their Closed Date in the future, at some point one or more of them did. It might have even been a requirement for them to provide a date in the future so the C-suite could understand which Opportunities might be closing, and when.
    • The problem this creates is that now a number of Opportunities may fail that validation rule and have to be updated after it is implemented. A couple of solutions to that may look like:
      1. Use ISCHANGED and ISNEW to ensure that the validation rule only fires when an Opportunity is first created and when the Close Date field is subsequently updated. This prevents an invalid Close Date from blocking a user who may not know what Close Date to use.
      2. Use Data Loader to mark Closed Dates which are in the future as blank. Make sure to check with stakeholders as this will impact reporting.
  4. How would this change impact the user experience?
    • This kind of fits in with part 3, as blindly implementing the validation rule without ISNEW or ISCHANGED checks or not going back to update invalid data can create a situation where an Opportunity cannot be updated until the validation error is resolved. The user encountering the error may also not be close enough to the sales process to know to change the Close Date field, or may not have access to do so.
    • Planning around this to ensure a lack of interruption is important for a good user experience.

2. I want to notify myself via email notification when an Opportunity [Amount] is changed to be greater than $250,000. What should I do?

  1. How would you accomplish this?
    • The easiest way to accomplish this is through a flow, setting it to send an email when an Opportunity’s Amount field becomes greater than 100k.
  2. Are there any other ways to accomplish this?
    • This can also be done through a workflow rule or a process builder, but the recommended method and the way Salesforce would recommend doing-so is through a flow.
    • A question could also be asked about whether this request might be better-suited for something like an approval process, where when an Opportunity amount exceeds $250k, the Opportunity is escalated to management for review. It would depend on the business’s actual goals, but notifying an individual of a change like this implies that the Opportunity is worthy of additional review.
  3. How would this change impact the user experience?
    • One thing to note here is that if the only criteria is whether an Opportunity’s Amount goes above $250k, then there’s a possibility that the recipient may receive multiple notifications for the same Opportunity, especially if synchronized quotes tend to change frequently. Additional criteria like only notifying when the amount goes from less than $250k to greater than $250k, or only notifying once the Opportunity is in a stage where less fluctuation occurs may be warranted to ensure the notification isn’t as noisy.

3. When an Opportunity is closed won, I want to submit this record for manager review, what should I do?

  1. How would you accomplish this?
    • Given that we asked for a way to submit the record “for manager review”, the answer we should be expecting is an Approval Process.
  2. Are there any other ways to accomplish this?
    • There are a couple of other ways to accomplish this, but they aren’t exactly the recommended solutions. On the business side, you could simply review any newly closed Opportunities during a regularly scheduled meeting. You could also utilize a combination of record types and flows to restrict access to an approval stage post-Opportunity-closure. It’s not ideal, but it is an option. You should expect the first answer however.
  3. Are there any other changes that might need to be made along with this change?
    • As part of the approval process, you’ll need to outline notification behaviors and/or whether the record should be locked. Outlining criterial requiring approval is also an important step. The business may want all Opportunities treated equally. They may also want to ignore Opportunities with an Amount below a certain threshold.
  4. How would this change impact the user experience?
    • Users should be notified of the new approval process, especially if your approval process implements record-locking so they understand why Opportunities may be locked. Additionally, there may be Opportunities which should have been reviewed, but which have passed over the approval process trigger. These may need to be reviewed outside that process, or if they fit within the approval criteria, may cause a large number of records to be impacted on go-live.

4. I would like a flow that is launched from Account on change, which checks if the NumberOfEmployees field is greater than 500, and if so, changes the Description field on the Account to “Big Company”

  1. How would you accomplish this?
    • The expected answer would be a Flow for this question
  2. Are there any other ways to accomplish this?
    • There are a couple of ways to accomplish this, including Process Builder and Apex Triggers
  3. Are there any other changes that might need to be made along with this change?
    • The request here is kind of unusual in-and-of itself, and so while this change is itself pretty simple, the user impact is significant and the approach should probably be revised. If you’re really going to do this, at least do yourself a favor and take a manual backup.
  4. How would this change impact the user experience?
    • This change would cause any accounts with >500 employees to have their Description be overwritten. That is… Probably not a great idea. To fit the requirements, you could try prefixing the Description with “Big Company” to avoid overwriting your teams’ hard work, but it would probably be better to do this work on a separate field, since the goals and the proposed solution doesn’t seem quite so well-aligned. Additionally, if this is just something needed for reporting, then Bucket Columns or Row-level formulas will do the job just fine.

5. A user wants to add a new field [Support Tier] to Account object, and should have a dropdown list of “Bronze”, “Silver”, and “Gold”.

  1. How would you accomplish this?
    • This is a pretty simple example for a picklist, on its face.
  2. Are there any other ways to accomplish this?
    • What’s being described here sounds much more like an Entitlement, which along with Milestones can help ensure that tickets are resolved within a desired timeline or escalated to ensure that a customer’s service-level is met.
  3. Are there any other changes that might need to be made along with this change?
    • As a picklist, it should probably also be pulled onto cases to help ensure that agents know how to prioritize cases. If done as an Entitlement, then the business needs to decide what kinds of Service Levels should be offered and what kinds of lead times should be offered to customers, keeping in mind agent throughput
  4. How would this change impact the user experience?
    • The picklist solution doesn’t change much about the user experience, except that Accounts will need to be populated with the new picklist. For entitlements, the users will need to be made aware of what the milestone graphics mean on cases (if you use them), as well as how cases should be escalated on higher support tiers. How cases should be prioritized and how to ensure that cases are resolved within the promised timelines are pieces agents should know how to complete as well.

6. I only want the Opportunity field [Primary Campaign Source] visible to “Marketing User” Profile. What should I do?

  1. How would you accomplish this?
    • The standard answer for this is to update the Field Level Security for this field to only give read access to the Marketing User profile.
  2. Are there any other ways to accomplish this?
    • Salesforce recommends simply copying the standard profiles, so before making changes, it’s recommended to duplicate the profile first and update access there and re-assign users to your new profile.
    • Another option is to grant access via Permission Set, but this is only really advantageous if users who should have access to this field may or may not be using the Marketing User profile
  3. Are there any other changes that might need to be made along with this change?
    • No other changes are necessary unless you’re cloning the Marketing User profile for the first time. Then you would need to clone the profile and re-assign users who are currently using the Marketing User profile.
  4. How would this change impact the user experience?
    • The field here would disappear for most users, and with it, a link to a related Campaign from the Opportunity. This could confuse non-marketing users who are accustomed to reviewing campaigns related to the Opportunity.

7. We only want to show a list of related Opportunity on an Account page to users whose profile is “Standard User”

  1. How would you accomplish this?
    • At its simplest, you can add the related list to the page layout, and then add the Opportunity related list to the lightning page layout, and then add conditional visibility to hide the component when the users’ profile isn’t Standard User
  2. Are there any other ways to accomplish this?
    • You could accomplish the opposite way as well by including the related list on the page layout for everyone, and just not including it for the lightning page layout for apps not used by the Standard User profile
    • You can also accomplish this by having separate page layouts by profile, so the layout for the Standard User profile would simply add the Opportunity related list to the page layout and the lightning page layout (or flexipage)
  3. Are there any other changes that might need to be made along with this change?
    • The first answer is pretty straight-forward. The latter 2 answers will require some planning, as additional page layouts and assignments would be required, as well as a understanding of who has access to the different lightning apps that are in use by your org.
  4. How would this change impact the user experience?
    • Not much changes about the user experience when it comes to the user experience (apart from the addition of this new field). It is worth noting though that it does take up real-estate on the page layout and that in a collaborative environment, a question may occasionally come up about why one user has this component, but another user does not.

8. I want to prompt a user to enter Opportunity [Closed Lost Reason] before marking the [Stage] as “Closed Lost”.

  1. How would you accomplish this?
    • The most typical way to accomplish this is to use a validation rule to check if the Opportunity is marked as Closed Lost, and display an error if the Closed Lost Reason is blank.
  2. Are there any other ways to accomplish this?
    • In the event that your Closed Lost Reason field is a picklist, you can actually use field dependencies and the Required flag to enforce this. Salesforce ignores the Required flag on a picklist field if there are no options available for the user to select. And since we would only provide Closed Lost Reason values when the Opportunity Stage is Closed Lost, that field would only become required once the user tried to move the stage to Closed Lost
    • Another option is to use separate page layouts and record types, but that’s an edge-case, and is not an optimal solution
  3. Are there any other changes that might need to be made along with this change?
    • Inevitably after making this sort of change, you will find out that you have some Closed Lost opportunities which have no Closed Lost Reason. Those will need to be corrected in order to stop this change from preventing additional changes to Opportunities which don’t currently comply with the new validation rule.
  4. How would this change impact the user experience?
    • The first example will simply alert users if they try to save an opportunity as Closed Lost without also providing a Closed Lost reason.
    • The second example will provide a visual cue to the user that Closed Lost Reason is now selectable once they move the stage to Closed Lost.
    • If you fail to update old Opportunity records, this change may block other teams from updating data on the Opportunity once it’s in Closed Lost, as they may not know which reason to enter, or that this new requirement is in-place. Sometimes it’s helpful to allow other users to update closed opportunities as you fill in your post-mortem on the lost deal.

9. 6 months after Opportunity Last Modified Date, I want to auto mark Opportunity [Stage] as “Closed Lost”.

  1. How would you accomplish this?
      • Using a process builder, you can set a trigger that when the Last Modified Date is updated on an Open Opportunity, after a 6 month delay, mark the Opportunity as Closed Lost. Conveniently enough, if Process Builder sees another one of these events is queued up, it will replace it with the new scheduled action.
    1. Are there any other ways to accomplish this?
      • This could also be done via a scheduled apex job, or via a schedule-triggered flow, both set to retrieve all Open Opportunities where the Last Modified Date is > 180 (ish) days ago, and mark them as Closed Lost
    2. Are there any other changes that might need to be made along with this change?
      • Users should obviously be made aware of this change, but in addition you may want to record somewhere like a Closed Lost Reason, that the Opportunity was Aged Out so it’s clear why it was closed. Obviously you want to also inform the Sales Managers.
      • In addition, as mentioned above, if you’re making a decision on behalf of users, you should inform them of why. This could be done via a notification to the Owner of the Opportunity that it was aged out.
      • It may also be worthwhile to add a flag to the Opportunity that Sales Managers can use to exclude this particular Opportunity record from automation if the Sales Manager is expecting a particularly long Sales Cycle.
    3. How would this change impact the user experience?
      • In addition to cleaning up the Opportunities automatically, you could accidentally pull the rug out of some users, as things like emails, chatter, and related tasks and events may not update the Last Modification date on an Opportunity. For a particularly long sales lifecycle, this is of significant importance as you don’t want to block users.

How to Interview A Salesforce Admin

Interviewing in general can be pretty awkward, and when someone isn’t trained or practiced interviewing, it can leave a lot of questions. How do I test this person’s skills? How do I test their decision-making abilities? Will they be able to work with our design philosophy? Do they know what they’re doing?

The approach that I like to take is very simple, and straightforward questions. Things like “How do you make a field required, but only once an Opportunity reaches the Contracting stage?”

When I ask a question like this, I’m looking for 4 things:

  1. Can the interviewee answer the question?
  2. Can the interviewee describe other solutions? And can they describe the benefits and caveats to the solutions they have proposed.
  3. Can the interviewee describe the impact of those changes to the data in Salesforce?
  4. How do those changes impact a user’s workflow?

Can the interviewee answer the question?

The first criteria is pretty typical. It’s a simple question, so an admin with a rudimentary understanding of the system should be able to answer it. Using the example question, we can say with confidence that you would use a validation rule to require the field be entered when the Opportunity stage reaches contracting.

This takes us to part two…

Can the interviewee describe other solutions?

Can the interviewee describe other solutions and the benefits or caveats to these solutions? There’s almost always a few different ways to solve problems in Salesforce, and an interviewee’s ability to describe these different options goes a long way toward understanding whether they know the “by-the-book” answer, or whether they understand the platform well enough to work around business rules or an environment’s own obscurities.

By extension of this, we want the interviewee to be able to understand the pros and cons of the proposed solutions. A validation rule handles this job perfectly, but has its own usability quirks. In my other post, I likened Validation Rules to a hammer, and that they’re often the first mechanism people run to for controlling input in lieu of other solutions. There are other options available, including:

  • Using record types and page layouts to require input at different stages
  • If the field is a pick list, we can use field dependencies and the required field checkbox to require selection after the contracting stage
  • Apex can also be used for restricting/requiring input
  • Utilizing proper field types that match the expected input and then using formula fields when we need to convert those values

Each of these has its own caveats:

  • Record types is messy on the admin side and requires automation to convert between types
  • Field dependencies really only works on picklist types
  • Apex is much more complex and suffers from the same after-submission error messages that validation rules do
  • And proper field typing requires you to be aware of the requirements before the field is created, or else a data migration is required. It also requires extra fields for the formulas if needed.

They also have their own benefits:

  • With varying record types and page layouts you can change how information is presented and hide anything which is no longer relevant
  • Field dependencies communicate expectations to the user up-front, rather than waiting for them to submit and requiring them to correct the mistake
  • Apex can be infinitely more complex than the other solutions
  • Proper field typing also communicates expectations to users up-front

It’s less important to know all of the solutions than to be able to recognize that other solutions exist, and be able to justify why you chose the solution you did.

Can the interviewee describe the impact of those changes to the data in Salesforce?

When a new field or automation is added to Salesforce, a pivotal question is whether the change will be a running change or if it also needs to be implemented retroactively. Understanding that a new validation rule which requires that a Closed Date cannot be set 1 week in the future has down-stream consequences is important.

Perhaps this business rule is new. Maybe there are a number of Opportunities out there which would not pass this validation rule. What happens then? What happens when a marketing resource changes an unrelated field on the Opportunity? Do we add an IsChanged expression to our formula so they don’t have to make the correction for the Sales Manager? Do we do a data load to clear out any Close Dates which are too far in the future? Or do we notify Sales in advance to update their close dates? And what happens if it’s not a close date, but another field instead where closed Opportunities might not pass the criteria going forward? If we have to data load or batch process them in the future, we may get blocked by this failing validation rule.

It’s once again far less important that the interviewee can come up with all these examples off-the-cuff, but important that they can talk through these and understands that every change and decision has consequences going forward.

How do those changes impact a user’s workflow?

The last piece is secretly one of the most important. In order to maintain a good relationship with the business and continue to grow your team, you have to be able to provide a tool that teams can use. Admins aren’t creating something they use day-to-day. They’re building something that the business users have to use day-to-day. That means considering how non-technical users will interact with the system, and ensuring that their experience is as easy as possible. Ensuring that the interviewee understands how their changes impact the user experience and how to mitigate and speed bumps that the change may create is critical to ensuring continued buy-in from the business and a happy, working relationship with the business going forward!

Example Interview Questions

I’ve gone ahead and written out some example questions, including the types of responses I look for in my other post, found here:
9 Example Admin Interview Questions