Change Overview

· Date: 11 Sep 2024

· Prepared by: Coresolute LLC

Description: -

Design is to implement the round-robin assignment for Ready and Working accounts for
Mid market, Enterprise and BDR Market Size. Also, Sales Rep can manually assign the
accounts to themself as needed.

Salesforce Components and Implementation Details:

Custom Meta Data :-

Account Ownership Type (Custom Metadata)

Overview:
The Account Ownership Type custom metadata type is used to store and manage the
ownership-related configurations of accounts in Salesforce, specifically for controlling account
assignment and ownership based on criteria like market size, intent score, and ownership
limits. Custom metadata types allow admins to define configurations and use them in code
without hardcoding, enabling more dynamic, scalable, and maintainable solutions.

Custom Fields:

1. Hard Limit (Hard_Limit__c):

Indicates the maximum number of accounts that can be owned by a user.
2. High Intent Score (High_Intent_Score__c):
Represents the intent score for account ownership priority.
3. Market Size (Market_Size__c):
Categorizes accounts based on market segmentation (e.g., Midmarket, Enterprise, BDR).
4. Soft Limit (Soft_Limit__c):
A threshold for account ownership that triggers reassignment before the hard limit is
reached.
5. Status (Status__c):
Specifies the status of the ownership type (e.g., Ready, Working).
6. Operator__c :
Specifies the operator of the ownership (e.g., Equals, Less Than, Greater Than etc.).
 7. Roles__c :
Specifies the Role of the user based on ownership type (e.g., Sales: Global MM SE,
Marketing: xDRs(BDR), Sales: International Enterprise SE etc.).

The Account_Ownership_Type__mdt custom metadata type enables dynamic account

assignment based on key criteria. It enhances flexibility and maintainability of the Salesforce
platform, allowing quick adaptation to business changes.

Region Mappings (Custom Metadata)

Overview:
The 'Region Mapping' metadata in Salesforce is used to manage the configuration of different
regions, sub-regions, roles, market sizes, and their associated statuses. It enables businesses to
customize sales, marketing, or other functional role assignments based on regional data. Here's
a breakdown of its key elements based on the shared information:

Custom Fields:

1. Region Mapping Name: Each record has a unique identifier such as "Reg_001,"
"Reg_002," etc., which represents different region configurations.
2. Label: The "Label" (e.g., Reg-002, Reg-004) provides a human-readable identifier for
each region mapping.
3. Sub Region: This field categorizes geographical areas, such as Americas, EMEAI (Europe,
Middle East, Africa, and India), and ANZ/AP (Australia, New Zealand, and Asia Pacific).It
helps in organizing and managing roles and operations by regional focus.
4. Roles: The "Roles" field defines specific roles assigned within each region. For example:
a. Sales: Americas Enterprise SE
b. Marketing: xDRs
5. Market Size:
a. Defines the size of the market each region targets. Examples include:
i. Enterprise (> $1B): Targeting large enterprises with revenue exceeding $1
billion.
ii. Midmarket (< $1B): Aimed at mid-sized companies.
iii. BDR: Focused on smaller or more specific business development roles.
b. Market size influences how roles and strategies are applied in different regional
segments.
 6. Status: The "Status" field tracks the readiness or activation of each region mapping
record. The shared metadata shows the status as "Ready," indicating these mappings
are currently in use and operational.
7. Customization: The 'Region Mapping' metadata allows for easy updates and changes,
reflecting the organization's evolving regional strategies. By configuring this metadata,
businesses can align roles and operations dynamically based on the region and market.

In summary, “Region_Mapping” metadata is a configuration tool in Salesforce that helps

businesses assign and organize sales and marketing roles, segment markets, and track status
across various geographical regions, ensuring tailored strategies for different areas of
operation.

Custom Labels :-
Manager_Email : It stores the manager email whichever we use in apex for email sending.
ACCOUNT_OWNERSHIP_ASSIGNMENT_EMAIL: It stores the template name and we used it in
Apex.
ACCOUNT_OWNER_FULLY_OCCUPIED_EMAIL: It stores the template name and we used it in
Apex.
ACCOUNT_NOT_FOUND_FOR_OWNERSHIP_EMAIL: It stores the template name and we used
it in Apex.

“Ready” Market Status Accounts Implementation Details :-

1. ReadyMidMarketScheduler
This is a Salesforce Schedule Apex class named ReadyMidMarketScheduler that implements
the Schedulable interface. This class is responsible for scheduling a batch process to execute.
The batch process is named RoundRobinBatchOnAccount and is designed to handle 'Ready'
Midmarket (<$1B) accounts.

1. The execute method is where the scheduling occurs. It creates an instance of the
RoundRobinBatchOnAccount class, passing in the desired state ('Ready') and the
market segment ('Midmarket (<$1B)') for the accounts to be processed. It then
executes the batch process using Database.executeBatch.

In summary, this code is a part of Salesforce's automation system that automates the process
of assigning accounts to different teams in a round-robin fashion based on their state and
market segment. The code is designed to be scheduled to run daily at a specific time.
2. ReadyEnterpriseScheduler
This is a Salesforce Schedule Apex class named ReadyEnterpriseScheduler that implements the
Schedulable interface. This class is responsible for scheduling a batch process to execute. The
batch process is named RoundRobinBatchOnAccount and is designed to handle 'Ready'
Enterprise (>$1B) accounts.

1. The execute method is where the scheduling occurs. It creates an instance of the
RoundRobinBatchOnAccount class, passing in the desired state ('Ready') and the
market segment ('Enterprise (>$1B)') for the accounts to be processed. It then executes
the batch process using Database.executeBatch.

In summary, this code is a part of Salesforce's automation system that automates the process
of assigning accounts to different teams in a round-robin fashion based on their state and
market segment. The code is designed to be scheduled to run daily at a specific time.

3. ReadyBdrScheduler
This is a Salesforce Schedule Apex class named ReadyBdrScheduler that implements the
Schedulable interface. This class is responsible for scheduling a batch process to execute. The
batch process is named RoundRobinBatchOnAccount and is designed to handle 'Ready' BDR
accounts.

1. The execute method is where the scheduling occurs. It creates an instance of the
RoundRobinBatchOnAccount class, passing in the desired state ('Ready') and the
market segment ('BDR') for the accounts to be processed. It then executes the batch
process using Database.executeBatch.

In summary, this code is a part of Salesforce's automation system that automates the process
of assigning accounts to different teams in a round-robin fashion based on their state and
market segment. The code is designed to be scheduled to run daily at a specific time.

4.RoundRobinBatchOnAccount

The RoundRobinBatchOnAccount class is a Salesforce Apex batch class that implements the
Database.Batchable and Database.stateful interfaces. This class is designed to perform a
round-robin assignment of accounts to users based on specified criteria.
1. The class is marked as global, which means it can be accessed from other classes and
contexts.
2. The class has several properties, including marketStatus, marketSize, accountSize,
assignAccountsUserIds, unAssignAccountsUserIds and regionWithRoles. These
properties are used to store information about the market status, market size, account
sizes, and user IDs for account assignments, unassignments and regionWithRoles.
3. The class has a constructor that takes in a market status, market size, and a list of
account sizes as parameters. These parameters are used to determine which accounts
should be assigned or unassigned. And it Fetches metadata (Region_Mapping__mdt) to
map sub regions with roles using market status and market size as filters.
4. The start method is used to define the initial query for fetching accounts. It takes a
Database.BatchableContext parameter BC. The method first queries for
Account_Ownership_Type__mdt records based on the marketStatus and marketSize
parameters. It then constructs a dynamic query to fetch accounts that meet certain
criteria, such as having a specific marketing status, type, and account size. The query
also checks for high intent scores and market sizes.
5. The execute method processes a batch of Account records and implements the round-
robin assignment logic. It takes two parameters: Database.BatchableContext BC and a
list of Account records (accounts). The method groups accounts by their subregion and
retrieves the corresponding roles from metadata (regionWithRoles). For each region,
the method invokes the RoundRobinController class to assign accounts to users based
on the predefined roles, market status, and market size. It then adds the assigned and
unassigned user IDs to the assignAccountsUserIds and unAssignAccountsUserIds sets,
respectively. The method ensures proper distribution of accounts among users while
considering specific role and region-based constraints.
6. The finish method is responsible for sending email notifications to users who were
either assigned or unassigned accounts, as well as to managers. It begins by fetching
email templates based on predefined labels, such as
ACCOUNT_NOT_FOUND_FOR_OWNERSHIP_EMAIL,
ACCOUNT_OWNERSHIP_ASSIGNMENT_EMAIL, and
ACCOUNT_OWNER_FULLY_OCCUPIED_EMAIL. These templates correspond to specific
scenarios: when no accounts are available for assignment, when users are assigned
accounts (for midmarket and enterprise segments), or when users are fully occupied
and unable to take on more accounts. After verifying the existence of these templates,
the method proceeds to send emails. If no accounts were assigned, a notification is sent
to the manager, using the template to provide relevant market status information. For
users assigned to accounts (specific to midmarket and enterprise), personalized emails
are sent, notifying them of the account assignments. Additionally, if users are
 unassigned, the method sends an email to the manager with the names of those users,
indicating that they couldn't be assigned accounts. All emails are sent in bulk using the
Messaging.sendEmail() method, with built-in error handling to log any issues
encountered during the process.

In summary, the RoundRobinBatchOnAccount class is a Salesforce Apex batch class that

implements the Database.Batchable and Database.stateful interfaces. This class is designed to
perform a round-robin assignment of accounts to users based on specified criteria. The class
has several methods, including start, execute, and finish, which are responsible for fetching
accounts, assigning accounts to users, and sending email notifications to users who were
assigned or unassigned accounts. The class uses a constructor to take in market status, market
size, and account sizes as parameters, and it stores information about assigned and unassigned
user IDs in the assignAccountsUserIds and unAssignAccountsUserIds properties.

5. RoundRobinController
This is a Salesforce Apex class named RoundRobinController that is responsible for the round-
robin assignment of “ready” market status accounts. The class contains a single method,
assignAccountToUser, which takes a list of Account records, a marketStatus, and a marketSize
as input and returns an AccountAssignmentWrapper object. The method uses the round-robin
algorithm to assign accounts to users based on their roles, market status, and market size.

1. The method begins by initializing an AccountAssignmentWrapper object to store the

assigned and unassigned user IDs. It then fetches the account ownership details from
the Account_Ownership_Type__mdt custom metadata type based on the market status
and market size.
2. Next, the method fetches all active users with specific roles in sales for account
assignment. It also gets the number of accounts owned by each user and stores the
count in a map.
3. The method then fetches the least active accounts based on task creation date and
ownership days. It stores the least active accounts per user in a map.
4. The method uses the round-robin mechanism to assign accounts to users. If a user has
fewer accounts than the soft limit or no accounts at all, the method assigns the account
to the user. If a user has more accounts than the soft limit but fewer than the hard limit,
the method reassigns the least active accounts of the user. If a user has reached the
hard limit, the method does not assign any more accounts to the user.
5. The method updates the Marketing_Status__c field of the assigned accounts to
'Working' and the Marketing_Status__c field of the least active accounts to 'Nurture'. It
 also updates the ownerId field of the least active accounts to the user with the highest
intent score.
6. Finally, the method returns the AccountAssignmentWrapper object containing the IDs
of the assigned and unassigned users.

The RoundRobinController class uses the round-robin algorithm to assign accounts to users
based on their roles, market status, and market size. The method first fetches the account
ownership details and the user information. It then uses the round-robin mechanism to assign
accounts to users based on their account count and the market status of their accounts. The
method also reassigns the least active accounts of a user to maintain the desired account
distribution.

“Working” Market Status Accounts Implementation Details :-

1. WorkingMidMarketScheduler
This is a Salesforce Schedule Apex class named WorkingMidMarketScheduler that implements
the Schedulable interface. This class is responsible for scheduling a batch process to execute.
The batch process is named WorkingRoundRobinBatchOnAccount and is designed to handle
'Working', Midmarket (<$1B) accounts.

1. The execute method is where the scheduling occurs. It creates an instance of the
WorkingRoundRobinBatchOnAccount class, passing in the desired state ('Working') and
the market segment ('Midmarket (<$1B)') for the accounts to be processed. It then
executes the batch process using Database.executeBatch.

In summary, this code is a part of Salesforce's automation system that automates the process
of assigning accounts to different teams in a round-robin fashion based on their state and
market segment. The code is designed to be scheduled to run daily at a specific time.

2. WorkingEnterpriseScheduler
This is a Salesforce Schedule Apex class named WorkingEnterpriseScheduler that implements
the Schedulable interface. This class is responsible for scheduling a batch process to execute.
The batch process is named WorkingRoundRobinBatchOnAccount and is designed to handle
'Working', Enterprise (>$1B) accounts.
 1. The execute method is where the scheduling occurs. It creates an instance of the
WorkingRoundRobinBatchOnAccount class, passing in the desired state ('Working') and
the market segment ('Enterprise (>$1B)') for the accounts to be processed. It then
executes the batch process using Database.executeBatch.

In summary, this code is a part of Salesforce's automation system that automates the process
of assigning accounts to different teams in a round-robin fashion based on their state and
market segment. The code is designed to be scheduled to run daily at a specific time.

3. WorkingRoundRobinBatchOnAccount
The code is a Salesforce Apex batch class named WorkingRoundRobinBatchOnAccount that
processes a large volume of Account records in a round-robin fashion based on predefined
criteria. The class implements the Database.Batchable<sObject> and Database.stateful
interfaces, allowing it to maintain state between batch executions.

1. The class is defined as global and implements the Database.Batchable<sObject> and

Database.stateful interfaces.
2. It includes a constructor to initialize the batch class with the market status, market size,
and account size.
3. The start() method creates a dynamic query to fetch Account records that match the
provided market status, market size, and account size. It returns a
Database.QueryLocator object containing the list of accounts to process.
4. The execute() method processes each batch of Account records in a round-robin fashion
using the WorkingRoundRobinController class.
5. The finish(Database.BatchableContext BC) method is a global method executed at the
end of a batch process, primarily designed to send email notifications when no accounts
are found for ownership. It begins by querying for an email template using its
DeveloperName, which is specified by the label
ACCOUNT_NOT_FOUND_FOR_OWNERSHIP_EMAIL. Once the email is prepared, it is
added to a list, and the emails are sent in bulk using Messaging.sendEmail(). The
method includes robust error handling, logging the outcome of each email send
attempt, including successful sends and detailed errors if any issues occur during the
process.

The code is designed to efficiently process a large volume of Account records in a round-robin
fashion based on the provided market status, market size, and account size. It leverages the
WorkingRoundRobinController class to handle the assignment logic and maintains state
between batch executions using the Database.stateful interface.
4. WorkingRoundRobinController
This is a Salesforce Apex class named WorkingRoundRobinController that implements logic for
round-robin assignment of accounts based on the ownership limits and activity criteria. The
class contains a single method, assignAccountToUser, which takes a list of Account records, a
marketStatus, and a marketSize as input parameters. The method assigns accounts to users
based on their market status, market size, and ownership limits.

1. The method begins by defining two lists: roleNames and accUpdateRecords. roleNames
is a list of role names that will be used to identify relevant users for account assignment.
accUpdateRecords is a list that will store Account records that need to be updated.

2. Next, the method fetches account ownership details based on the marketStatus and
marketSize parameters. These details determine the soft and hard limits for account
ownership. The method then assigns role names based on the marketSize parameter.

3. The method proceeds to fetch active users based on specific roles to be assigned
accounts. It also fetches the current number of accounts each user owns for limit
checks. The method loops through each Account record in the input list and checks if
the user has exceeded their hard account ownership limit. If the limit is exceeded, the
method reassigns the least active accounts to the marketing user.

4. Finally, the method tries to update all the modified accounts in the database. If any
exceptions occur during the update, they are caught and logged.

Overall, the code implements a round-robin assignment of accounts based on ownership limits
and activity criteria. The method assigns accounts to users based on their market status and
market size, and reassigns least active accounts to the marketing user if the ownership limit is
exceeded.

Flows for Manual Assignment of Accounts by Sales Rep:-

Create New Field on Account Object:
Manual_account_assignment_date__c (Custom Field):
The Manual_account_assignment_date__c field stores the date when a user manually requests
an account assignment. It is useful in Schedule-Triggered Flow.

Request For Account (Quick Action):

This quick action is designed to invoke the screen flow named "Marketing Owned Account
Manual Assignment." It is conveniently placed on the record page of the account for easy
access.

Marketing owned account manual assignment (Screen Flow) :

Overview :
This Screen Flow is designed to facilitate the manual assignment of accounts to the current
logged-in user, specifically targeting Sales Representatives. It incorporates multiple screens and
decision elements to ensure a seamless and efficient user experience. The flow dynamically
evaluates user roles and applies account ownership limits to manage account assignments
effectively.

Flow Process :

1. Role Verification:

 The flow includes decision logic to verify if the current user has the required role,
specifically the "Request for Account" role.
 If the role matches, the user is identified as a Sales Representative.

2. Account Ownership Count:

 After confirming the user’s role, the system retrieves the number of accounts currently
owned by the Sales Representative.

3. Dynamic Limits Based on Metadata:

 The flow references a custom metadata type called Account Ownership Type to retrieve
soft and hard limits on account ownership, which are based on the user’s role.
 These limits are used to govern the account assignment process and ensure that
account allocation remains within defined thresholds.

4. Account Assignment Logic:

  Scenario 1: If the number of owned accounts is below the soft limit, the system directly
assigns the new account to the Current Sales Representative User and changes the
marketing status to ready with etc fields.
 Scenario 2: If the number of owned accounts is between the soft and hard limits, the
flow selects accounts with lower activity currently owned by the Sales Representative
and reassigns them to the hubspot integration user and changes the marketing status
and nurture assignment date fields.

Flow Dynamics:

 The flow is fully dynamic, adjusting both soft and hard account ownership limits based
on the user's role. This flexibility ensures that the system can accommodate changes in
role assignments and automatically enforce the appropriate limits.
 The process prioritizes user experience, making the account assignment process
streamlined and intuitive while ensuring that account distribution aligns with business
rules.

Schedule Flow For Non-Activity Accounts (Schedule-Triggered Flow) :

Overview:
This is a schedule-triggered flow designed to reassign accounts that have not had activity in the
past 48 hours. The flow is scheduled to run at specific intervals, automatically identifying
inactive accounts, reassigning ownership to a designated HubSpot integration user, and
updating key account fields.
Flow Process:
1. Identify Inactive Accounts:

 The flow retrieves all accounts where:

o The most recent task creation date is either null or less than or equal to 2 days
from the current date.
o The manual assignment date is exactly 2 days prior to the current date.

2. Account Reassignment and Field Updates:

 For the accounts identified:

o The Owner is updated to the HubSpot integration user.
o The Marketing Status field is updated to “Nurture.”
o All relevant records are updated to reflect the changes in ownership and status.
Key Features:

 This flow ensures timely reassignment of inactive accounts, freeing them up for further
nurturing by the marketing team.
 The flow is fully automated and runs on a set schedule, ensuring that no manual
intervention is needed to manage inactive accounts.
 The automation minimizes manual workload and ensures that accounts without recent
activity are efficiently reassigned.