Static Dashboard :
Static dashboards in Salesforce are typically used for presenting historical or
static data, making them suitable for situations where data doesn't frequently
change, such as annual reports or archived metrics. They offer stability in data
presentation but require manual intervention to reflect any updates.
Data Refresh:
Static dashboards display a snapshot of data at a specific point in time and do
not automatically update.
User View:
All users see the same data, which is determined by the dashboard's running
user.
Use Cases:
Suitable for general reporting and tracking key metrics across the organization,
as well as historical data or archived metrics where real-time updates are not
necessary.
Example:
An executive might want a static dashboard showing overall sales performance
for the last quarter, accessible to all sales managers.
______________________________________________________________________
Dynamic Dashboard :
Dynamic dashboards, on the contrary, cater to dynamic environments where real-time
data is essential for decision-making. They enable users to stay informed with the latest
information without the need for manual refreshes, enhancing productivity and enabling
proactive decision-making based on current insights.
Data Refresh:
Dynamic dashboards update in real-time, displaying data relevant to the user
viewing the dashboard.
User View:
Each user sees data based on their own permissions and role, providing a
personalized view.
Use Cases:
Ideal for situations where users need to see data specific to their role, team, or
territory, and where real-time data is crucial.
Example:
A sales representative can see their own pipeline data on a dynamic dashboard,
while a sales manager can see the combined pipeline data for their entire team,
all from the same dashboard.
______________________________________________________________________
Roll-up Summary Field :
A Roll-up Summary field in Salesforce aggregates data from child records to a
parent record within a master-detail relationship. This field type allows you to
perform calculations like counting, summing, finding minimum or maximum
values on related records, streamlining data analysis and reporting.
Key features and uses:
Master-detail relationship:
Roll-up summary fields are exclusively available for objects that have a
master-detail relationship. This means one object (the master or parent) controls
certain behaviors of the other (the detail or child).
Aggregation functions:
They can perform calculations like:
● COUNT: Counts the number of related records.
● SUM: Totals the values of a specific field in the related records.
● MIN: Finds the lowest value in a specific field.
● MAX: Finds the highest value in a specific field.
Filter criteria:
Roll-up summary fields can also include filter criteria to narrow down the records
being summarized. For example, you could sum the values of won opportunities
related to an account, excluding those that are not closed.
Example:
You can use a roll-up summary field on the Account object to display the total
value of all related Opportunities, or the number of open opportunities.
Benefits:
Roll-up summary fields simplify data aggregation, eliminating the need for
custom Apex triggers and reducing reliance on technical expertise.
______________________________________________________________________
Role vs Profile :
In Salesforce, roles and profiles work together to manage user access and
permissions. Roles primarily control what records a user can see based on
their position in the organization's hierarchy. Profiles, on the other hand,
define what a user can do with those records, such as creating, editing, or
deleting, as well as access to specific features.
Roles in Salesforce:
Hierarchy:
Roles are organized in a hierarchy that reflects the organizational structure, with
higher roles having access to data owned by lower roles.
Record Visibility:
Roles determine which records a user can view and access based on their
position in the hierarchy.
Reporting Structure:
Roles are used to establish reporting structures and define who reports to whom.
Profiles in Salesforce:
Permissions and Access:
Profiles define the specific permissions and access rights for users, controlling
what they can do within the platform.
Object and Field Access:
Profiles determine which objects, fields, and data a user can access and interact
with.
Baseline Authorization:
Each user is assigned a profile, which serves as the baseline for their access
rights within the organization.
Standard and Custom Profiles:
Salesforce offers standard profiles with pre-defined permissions and the ability to
create custom profiles to meet specific needs.
In essence: Roles determine "who can see what", while profiles determine
"who can do what" in Salesforce.
______________________________________________________________________
Different Relationships In Salesforce :
Salesforce offers several types of relationships between objects, with the most
common being Master-Detail and Lookup relationships. Other types include
External Lookup, Hierarchical, and Self relationships. These relationships
allow you to connect records across different objects, creating a network of
related data within your Salesforce instance.
Here's a breakdown of the main types:
1. Master-Detail Relationship:
Strongly coupled:
The "master" object controls the "detail" object, including sharing and security
settings.
Cascade Deletion:
If the master record is deleted, the related detail records are also deleted (unless
reparenting is enabled).
Roll-up Summary Fields:
Master-detail relationships allow the creation of roll-up summary fields on the
master object, which aggregate data from the detail records.
Example:
A "Contract" object (master) and a "Contract Line Item" object (detail), where
each contract has multiple line items.
2. Lookup Relationship:
● Loosely coupled: The relationship is more flexible, and deleting a record in one
object doesn't automatically delete the related record in the other.
● No Roll-up Summary Fields: Lookup relationships do not support roll-up
summary fields.
● Example: An "Account" object (master) and a "Contact" object (detail), where an
account can have multiple contacts.
3. External Lookup Relationship:
● Connects a Salesforce custom object to an external object in an external data
source.
4. Hierarchical Relationship:
Special Lookup:
A special type of lookup relationship available only for the "User" object.
Organizational Hierarchy:
Used to model reporting structures and relationships between users within an
organization.
5. Self Relationship:
● Object linked to itself: A lookup relationship where an object is related to itself.
● Example: An "Employee" object where one employee can be the manager of
another employee, creating a relationship within the same object.
______________________________________________________________________
Different Sharing Rules In Salesforce :
Salesforce has two main types of sharing rules: Owner-based Sharing Rules
and Criteria-based Sharing Rules. These rules allow administrators to extend
data access beyond the default organization-wide defaults.
1. Owner-based Sharing Rules:
● Purpose: These rules grant access to records based on their owner. If a user
owns a record, or is in a role or public group that owns records, they can be
granted specific access levels.
● Example: A sales manager in the US might need to see opportunities owned by
sales managers in the APAC region. An owner-based sharing rule could be
created to grant this access.
● Sharing Based On: Roles, Public Groups, or Roles and Subordinates.
2. Criteria-based Sharing Rules:
● Purpose: These rules grant access to records based on specific criteria (field
values). If a record meets a certain condition, the rule will determine which users
get access.
● Example: If you have a custom object for job applications and want to share all
applications with the "IT" department with all IT managers, a criteria-based
sharing rule can be used.
● Sharing Based On: Record values (not the owner).
In summary, owner-based sharing rules are focused on record ownership,
while criteria-based sharing rules are focused on record content. Both types of
sharing rules are used to broaden data access beyond the organization-wide
defaults.
______________________________________________________________________
Import Wizard & Data Loader :
Salesforce provides two primary tools for importing data: the Data Import
Wizard and the Data Loader. Each tool is designed for different scenarios and
data volumes.
Data Import Wizard:
Functionality:
An in-built, web-based tool accessible directly within Salesforce Setup. It offers a
user-friendly, step-by-step interface for importing data.
Capacity:
Suitable for smaller data volumes, typically up to 50,000 records at a time.
Supported Objects:
Supports common standard objects like accounts, contacts, leads, campaign
members, person accounts, and custom objects. It does not support all standard
objects, such as cases or opportunities.
Operations:
Primarily used for inserting new records, updating existing records, and upserting
(inserting or updating) records.
Ease of Use:
Designed for users with varying technical expertise due to its intuitive wizard
interface.
Data Loader:
Functionality:
A client application that needs to be installed on your local machine (Windows or
Mac). It offers more advanced capabilities for data manipulation.
Capacity:
Designed for larger data volumes, capable of importing up to 5 million records (or
more with command-line operations) of any data type.
Supported Objects:
Supports all standard and custom objects in Salesforce.
Operations:
Offers a wider range of operations, including insert, update, upsert, delete,
export, and hard delete.
Automation:
Supports command-line operations for automated batch processes and
scheduled exports, making it suitable for recurring data management tasks.
Field Mapping:
Provides full control over field mappings, including the ability to create and reuse
mapping files for complex scenarios.
Choosing the Right Tool:
Use the Data Import Wizard
for simple, one-time imports of smaller data sets into supported standard or
custom objects.
Use the Data Loader
for large-scale data imports, complex data transformations, operations on
unsupported standard objects, or when automation and advanced features like
hard delete are required.
______________________________________________________________________
Workflow & Trigger :
In Salesforce, both workflows and triggers automate tasks, but they differ in
their functionality and implementation. Workflows are a declarative,
point-and-click tool used for simple automation, while triggers are code-based
and offer more flexibility for complex logic.
Workflows:
Declarative:
Workflows are configured using a point-and-click interface, not requiring coding.
Limited Actions:
Workflows can only perform actions like sending emails, creating tasks, updating
fields, or sending outbound messages.
Limited Scope:
Workflows typically work within a single object and can cross objects in a
master-detail relationship.
Time-Based Actions:
Workflows can be configured to trigger actions at specific times or intervals.
Example:
Sending an email alert when a lead is updated to a certain stage.
Triggers:
Code-Based:
Triggers are written in Apex, Salesforce's programming language, allowing for
more complex logic and customization.
Before and After Events:
Triggers can execute code before or after record creation, update, deletion, or
undeletion.
Broader Scope:
Triggers can work across multiple objects and handle more complex scenarios,
including roll-up summaries and data manipulation.
Example:
Calculating the total value of all opportunities associated with an account.
Key Differences Summarized:
Feature Workflow Trigger
Implementation Declarative (point-and-click) Code-based (Apex)
Complexity Simple automation Complex logic and customization
Scope Single object, master-detail relationships Multiple objects, complex
scenarios
Actions Limited to tasks, emails, field updates, Can handle any Apex logic
outbound messages
Use Cases Basic automation, email alerts, etc. Complex calculations, data
manipulation, etc.
When to use which?
Use workflows
for simple automation tasks that don't require complex logic or calculations.
Use triggers
when you need more flexibility, complex logic, or need to work across multiple
objects.
Important Note: Salesforce has been encouraging the use of Flows as the
preferred automation tool, as they combine the declarative nature of
workflows with more advanced features.
______________________________________________________________________
Workflow vs Flow :
No, Workflow and Flow are not the same in Salesforce, though both are
automation tools. Workflow rules are a simpler, older automation tool, while
Flows are more powerful and versatile, offering more complex automation
capabilities and user interaction.
Here's a breakdown:
Workflow Rules:
● Purpose: Automate simple actions like sending email alerts, field updates, or
creating tasks based on predefined criteria.
● Execution: Always run behind the scenes.
● Complexity: Limited to basic actions and single object automation.
● Example: Sending an email alert when a lead is assigned to a specific user.
Flows:
● Purpose: Automate more complex business processes, including user
interactions, data manipulation, and actions across multiple objects.
● Execution: Can run behind the scenes or provide screens for user input and
guidance.
● Complexity: Supports complex logic, branching, and user interaction.
● Example: Guiding a user through a multi-step process to create a new
opportunity and related records, including collecting data via screens.
Key Differences:
User Interaction:
Flows can incorporate user interaction through screens, while workflow rules
execute automatically without user input.
Complexity:
Flows can handle more complex logic, branching, and data manipulation than
workflow rules.
Object Scope:
Flows can automate actions across multiple objects, while workflow rules are
generally limited to a single object.
Migration:
You can migrate multiple workflow rules into a single flow, but not the other way
around.
In essence: If you need to automate a simple task, workflow rules might be
sufficient. However, for more complex processes requiring user interaction or
data manipulation across multiple objects, Salesforce Flows are the
recommended tool.
______________________________________________________________________
Data Level Security in Salesforce :
Salesforce employs a layered security model to control data access, ensuring
that only authorized users can see and interact with specific information. This
model includes organization-wide defaults, role hierarchies, sharing rules, and
profiles/permission sets, which work together to manage access at different
levels: object, field, and record.
Here's a breakdown of the key elements:
1. Organization-Wide Defaults (OWD):
● OWDs define the baseline level of access for all users within an organization.
● They specify the most restrictive access level for an object, such as "Private,"
"Public Read Only," or "Public Read/Write".
● OWDs can be further refined by other sharing mechanisms like role hierarchies
and sharing rules.
2. Role Hierarchies:
● Role hierarchies represent the organizational structure and how users relate to
each other.
● Users higher in the hierarchy typically have access to data owned by users below
them.
● This allows for a more granular level of access control than OWDs alone.
3. Sharing Rules:
● Sharing rules allow administrators to grant broader access to records beyond
what's defined by OWDs and role hierarchies.
● They can be based on record ownership, criteria, or guest user access.
● Sharing rules can be used to open up access to specific groups of users or to
automate access based on certain conditions.
4. Profiles and Permission Sets:
● Profiles control access to objects, fields, record types, tabs, apps, and other
Salesforce features.
● Permission sets extend or grant additional permissions to users without
modifying their profiles.
● They offer a more flexible way to manage user permissions, especially when
users need access to specific features or data beyond what their profile provides.
5. Object-Level Security:
● Object-level security determines whether a user can create, read, edit, or delete
records for a specific object (e.g., Accounts, Opportunities).
● This is managed through profiles and permission sets.
6. Field-Level Security:
● Field-level security allows administrators to control which fields users can view
and/or edit within an object.
● This provides a granular level of control over data access, preventing users from
seeing sensitive or irrelevant information.
● Similar to object-level security, it's managed through profiles and permission sets.
7. Record-Level Security:
● Record-level security controls which specific records a user can access.
● It is determined by a combination of OWDs, role hierarchies, and sharing rules.
● For example, even if a user has access to the "Accounts" object, record-level
security might restrict them to only seeing accounts they own or that are shared
with them.
______________________________________________________________________
Junction Object in Salesforce :
In Salesforce, a junction object is a custom object that creates a
many-to-many relationship between two other custom or standard objects. It
acts as a link, allowing records from each object to be associated with multiple
records from the other. This is achieved by creating two master-detail
relationships on the junction object, one to each of the related objects.
Purpose:
● Junction objects are essential for modeling many-to-many relationships where
records from one object can be related to multiple records in another object, and
vice versa.
● They help avoid data redundancy and maintain a clean data structure by acting
as a bridge between the two related objects.
How it works:
● A junction object is a custom object, meaning it's created by a Salesforce
administrator or developer to meet specific business needs.
● It includes two master-detail relationships, one to each of the objects participating
in the many-to-many relationship.
● For example, if you have a "Project" object and a "Consultant" object, you can
create a junction object called "Project Assignment" with master-detail
relationships to both "Project" and "Consultant". This allows a consultant to be
assigned to multiple projects, and a project to have multiple consultants assigned
to it.
Key characteristics:
Many-to-many relationship:
The core function of a junction object is to establish a many-to-many relationship
between two objects.
Custom object:
Junction objects are custom objects, meaning they are created specifically for the
purpose of modeling a particular relationship.
Master-detail relationships:
Junction objects have two master-detail relationships, which is how they connect
to the other two objects.
Roll-up summary fields:
Because of the master-detail relationship, you can create roll-up summary fields
on the parent objects to aggregate data from the junction object.
Example:
Imagine a scenario where you have standard Salesforce objects: Accounts
and Opportunities. You want to track which contacts are involved in which
opportunities, and you also want to track the specific role each contact plays
(e.g., Decision Maker, Influencer, etc.).
● You would create a custom junction object, perhaps named "Opportunity Contact
Role".
● This object would have two master-detail relationships: one to the Opportunity
object and one to the Contact object.
● You would then add fields on the junction object to capture the role of the contact
in the opportunity (e.g., a picklist field for "Role").
By using a junction object, you can efficiently manage these complex
many-to-many relationships within your Salesforce org.
______________________________________________________________________
