Placeholder Users in Forecast
Placeholder Users
In certain use cases, you might need to create a placeholder user in your CRM to roll up or bucket the correct portions of the hierarchy in Forecast. Here are a couple of scenarios we've encountered with Clari customers:
- You have a sales leader/manager with sales reps that report directly to them across multiple regions, but the sales leader needs to submit a forecast call at each regional level.
- A sales leader leaves your organization, and you are awaiting a backfill.
- If you're tracking velocity/churn/run-rate business, then there might not be a specific manager that submits a forecast for segments of business that fall outside the Sales team, but you need to have visibility into this forecast in your Forecast Module.
These are just a couple of examples in which you would implement a placeholder user to be able to submit a forecast or have the correct roll-up in Forecast.
Creating Placeholder Users
It’s important to know that the placeholder user must be created in your CRM for Clari to be able to leverage the user in Forecast.
1. Create a user in your CRM to use as a placeholder.
You can use an active or inactive user for this placeholder. Most customers use an inactive use to avoid consuming an SFDC license. Instead of creating a new user, some users repurpose an existing or old user to create the placeholder. This can be confusing as the user will have the same name in Clari that it has in your CRM. The best practice is to change the user's name that you're repurposing.
2. Ideally, the email address of the placeholder user should be an alias of an existing email address of a current user in Clari.
If you use Gmail, check out their article with steps for creating an email alias here.
If you use Microsoft Exchange, check out their article with steps for creating an email alias here.
3. Ensure the user is assigned the correct role in your CRM so they are placed correctly in the role hierarchy where the placeholder is needed.
Example
Organization ABC has a North America team, but only has managers for West and Central. The East manager recently left the organization, and the CRO will need to submit a forecast on behalf of the East team until a replacement is hired.
Here's what the hierarchy and rollup structure would look like in this scenario:
- CRO
- West - Manager 1
- Central - Manager 2
- East - Placeholder (this is where the placeholder user needs to sit in the role hierarchy in your CRM)
Backfilling is one of many scenarios where you may need to use a placeholder user. Other examples for the placeholder user include having an additional placeholder user for a player/coach scenario or breaking out reps into regions that all roll up to the CRO directly.
For example, some organizations will use a placeholder user to separate out channel teams.
Key Considerations
Backfilling
Suppose you require that the CRO make a forecast submission for another manager/territory (i.e., in our example, the CRO needs to submit for the East team). In that case, the CRO will need permission to directly edit the forecast submissions for all users that roll up to the CRO. This removes the ability of the CRO to make adjustments.
An alternative option in this use case includes allowing the CRO to use another active user from your CRM and login via that other user to submit the East team's forecast call in Clari. However, we strongly recommend not giving individual users multiple Clari logins. A better alternative option is to have your Operations team submit the forecast on behalf of the CRO as a Viewer in Forecast.
Player/Coach
In the player/coach use case, the key factor to consider before creating a placeholder user is that you must reassign opportunities to the user instead of the manager.
Territories
Salesforce Territories 1.0 or 2.0 are options that help solve the need for placeholder users since forecasts are assigned at the territory level, not the user level. This allows for the continuation of forecast submissions even if individual users have left the organization without needing to create placeholders.
There is also a lot more flexibility regarding overlay teams, and the player/coach scenario — since a manager can have a territory and an individual quota.
