A Shared Environment¶

Many people and many teams use one org. What one of them builds, the others see, and often depend on. This page explains the principle of A Shared Environment: how to keep the org clean and uncluttered, and how to stop one user from building something that gets in the way of other users.

Who Creates Shared Things¶

• Every user can make things for their own use: a private list view, a private report, a private email template.
• Few people can make a thing that every user sees. Salesforce has a permission for each kind. Two examples are Manage Public List Views and Manage Public Lightning Email Templates; reports, dashboards, and their folders have permissions of their own (User Profile permission descriptions).
• A permission set gives such a permission to the people who look after shared things, and to nobody else (The Principle of Least Privilege).

Names and Descriptions¶

• The name of a shared thing says what it shows, and it stays true. A public list view named All Accounts that someone has filtered to active accounts has a name that is no longer true.
• Each kind of shared thing has one naming pattern, which the organisation chooses.
• A shared report or dashboard has a description, so that a user knows what it is for before opening it (Readability).

List Views¶

• The API name of a list view must be unique. A user who saves a private list view with a common name, such as All Accounts, takes that API name, and no other user can then use it. Nothing prevents this.
• The label of a list view does not have to be unique, and two views with the same label confuse the people who use them. An organisation may want a script that reads the list views in version control and reports the labels that are used more than once. A PMD rule could perhaps do the same. These standards mention the check, and give no sample of it.
• Each organisation decides how a public list view changes. Some require that the change goes through version control. Others wait for a user to submit a ticket.

Reports and Dashboards¶

• A report that other people rely on is in a public folder with a name that says whose it is and what it is for. What belongs in version control, and how folders are shared, is on the Analytics page.
• One dashboard serves a whole team. Nobody builds a copy of a dashboard, with its own folder of reports, for each member of a team: that does not scale.
• A dashboard shows each person their own data in one of two ways. The first choice is a filter on the dashboard, which the viewer sets. The second is a dashboard that runs as the person who views it, or that lets the viewer choose whom to view it as (Configure Dashboard Data Visibility). An org has few dashboards of the second kind: up to 5 in Enterprise Edition, and up to 10 in Unlimited and Performance Editions (Reports and Dashboards Limits and Allocations).

Clean Up on a Schedule¶

• Clutter builds up in every space that users share, and someone removes it on a schedule.
• The Unfiled Public Reports folder is cleared out weekly, so that nobody relies on a report that was never meant to last. Other shared spaces are tidied on a similar schedule.

Change and Feature Requests¶

A user who needs a change asks for it in one place. An organisation has one system for change requests and feature requests, and each request has a priority.

The person who submits a request can say how urgent it is. The support team then sets its priority, and the priority sets the goal time to resolve it.

The priorities, from the most urgent:

Each organisation sets the goal time to resolve for each priority.