30 Admin Questions Flashcards
What is a Profile?
Profiles and Roles work together to determine which records users can see and what they can do with them. Profiles are always required and control which objects and fields users can access. They also determine whether users can create, edit, or delete records.
What is a Role?
Roles are technically optional, but it’s a good practice to use them. Roles are predominately about sharing records to users. When organization-wide default sharing is set to lower than Public Read/Write for an object, you can use Roles in Sharing Rules to determine which records (and whether they’re Read-Only or Read/Write) that users can view.
Roles also have a hierarchy like an organization chart, so that the sharing can cascade beyond records users need, but also for managers to access their team’s records.
What is a Permission Set?
Permission sets are add-ons to profiles. They generally have the same settings and are used to increase users’ permissions above what the profile provides. The benefit is that you can give users slightly different permissions without having to create separate profiles.
This reduces the overhead for administrators. It’s useful to think of profiles as the base set of permissions that many users have in common while permission sets are the ‘extra’ permissions that fewer users need. You can also group multiple permission sets together by job function via Permission Set Groups for simpler and more consistent administration. Salesforce and Trailhead have useful articles on the subject.
What is a Public Group?
Public Groups are similar to Roles what Permission Sets are to Profiles. An Administrator can create ad hoc groups of users (naming them individually or by Roles) to be able to share records to them.
A common use case is to share records to users of a similar level, say Directors. As there are probably Directors spread throughout the organization, they aren’t likely to be under each other in the Role hierarchy, but an Admin could create a Public Group with all of the Director Roles in it and share records to the group.
What is a Queue?
Queues are similar to public groups in that they are bespoke groupings of users (named individually or via roles), but they are used for record ownership rather than sharing rules. The classic use is for Cases – where you’d want to assign an open one to a team of people so that whoever is available first handles it. Queues are available on all custom objects and many standard objects.
What is a lookup relationship?
A lookup relationship allows you to relate records to each other, creating a parent-child schema. Generally, this is done between the different objects (such as Accounts and Contacts), but it can be one object (such as Parent Accounts). Relationship fields allow for users to specify how records affect each other and help with reporting.
What is a master-detail relationship?
Master-Detail relationships are similar to lookup relationships, but have a few special features. First, Master-Detail allows for Roll-up Summary fields to be created. This relationship type also affects security in that the Detail (or child) record does not have a record owner. It inherits its visibility from the Master (or parent) record. That can be very beneficial, or limiting, depending on your use case.
What is a Roll-up Summary field?
A Roll-up Summary field is available on the master side of a Master-Detail relationship. It allows administrators to aggregate data from related detail records (count them, sum a numeric value on them, etc.) in real time. Ability to have Roll-up Summary fields is the top reason why you’d consider a Master-Detail relationship.
What are different types of fields?
Field types define the type of information you expect users to enter for that field. Examples include Text, Number, Date, Currency, etc. It’s important to match the field type to the data because it affects your ability to report on and analyze the data. For example, you could store numbers in text fields, but that would make performing calculations on them needlessly challenging.
What are Validation Rules?
Validation Rules allow you to enforce specific business logic to help with your org’s data integrity. You can specify conditions on an object that aren’t allowed to exist.
For example, if you don’t want a user to mark an Opportunity as Closed Won if the Account doesn’t have a Billing Address. You can add a Validation Rule so that when a user tries, it won’t update the Opportunity record and displays an error message explaining what they need to do.
What if you need roll-ups on a lookup relationship?
Sometimes you’d like to aggregate child data on a parent record, but you can’t use Master-Detail due to the security limitations not aligning with your use case. In those situations, you could write code or use Flow Builder to replicate the functionality of Roll-up Summary fields.
Most likely, however, you’ll want an app from the AppExchange to make configuration easy. In fact, an app like this is one of the first things you should look to install in your org (in a sandbox first, of course.)
What is a junction object?
A junction object is a term to describe an object that is designed to have two different parent objects (generally with Master-Detail relationships) which forms a many-to-many relationship. There is nothing labeled “junction object” within Salesforce; it’s a definition applied to an object based on its function in the data model.
A common use case is something like Classes in a school. The school will offer many Courses and have many Students. Each of those will be connected to many Classes.
What is a Flow?
Flow is an admin’s primary declarative automation tool. Flow can perform actions such as creating, updating, and deleting records as well as sending emails, outbound messages, launching other flows, and calling Apex code. Flow is also the only declarative automation tool that allows admins to build custom screens to interact with users, and can greatly improve the user experience.
The most common ways for flows to be triggered are via record changes, screens, or on a schedule.
Salesforce has also launched Flow Trigger Explorer, which allows admins to determine the order in which flows run, as well as Flow Orchestrator.
What is happening with Workflow Rules and Process Builder?
Both declarative tools were predecessors to Flow and are no longer necessary (now that Flow can do everything they can do!). It’s important to know that existing workflow rules and processes will continue to operate as they have, but best practice is to create all new declarative automation using Flow.
Salesforce is developing tools to help admins migrate older automation to Flow.
Isn’t it a problem to have multiple flows on the same object?
While that may have been true once, it no longer is. With Flow entrenched as the primary declarative automation tool, there will be instances when flows are triggered on the same object.
In Spring ‘22, Salesforce introduced Flow Trigger Explorer, which allows admins to set the order in which separate flows run. There’s also a tool called Orchestrator that allows admins to develop multi-user, multi-step automation. Check out the Orchestrator Basic Trailhead module.
