Posts

From Sunil Nandipati: Deploying Salesforce Scheduler from Sandbox to Production Environments

Preface

Customers who have a streamlined development processes typically use multiple non-production environments (one for each probably – development, QA, integration, data migration, SIT and UAT). And it is a general practice that development teams develops in development sandboxes first, check in their code to a repository and adds instructions to deployment trackers – for deployment teams to perform the deployment steps. These can include any manual steps – related to enabling features, adding data etc. Typically anything that cannot be done using the metadata API.

Context

Salesforce Scheduler provides a guided setup experience to setup the product for use. It is NOT a good practice to expect the deployment teams to repeat these steps manually in every single Org. Reasons can be many. To quote a few – prone to human errors while executing manual steps, time consuming, too much detailed documentation will be required and some customers do NOT prefer a partner or consultant to have administrator access to environments other than development.

Guidelines while deploying Scheduler

While deploying Salesforce scheduler between environments – consider categorizing your components into the following areas

Pre deployment activities

Include steps that need to be performed before migrating the codebase using the Metadata API. These can be manual steps for features that are NOT yet supported by the MetaData API (or) any dependent packages that are required for your implementation.

Deploy code using Metadata API

Step 1 – Include feature settings that are related to “Salesforce Scheduler Settings” which need to be either Enabled or Disabled, should be covered first
Note: The settings mentioned in Italic and which do NOT have a Metadata Reference are currently NOT supported by Metadata API – will be addressed in future releases (Safe harbor). If you are using these features – activate them manually as part of your pre-deployment steps

Salesforce Scheduler SettingsMetadata Reference
Event ManagmentenableEventManagementOrgPref
Block Resource AvailabilityenableBlockResourceAvailabilityOrgPref
Multi Attendee EventenableCreateMultiAttendeeEventOrgPref
Appointment Distribution
Aggregate Resource Use
Publish Appointments as Platform Events
Multi Resource SchedulingenableMultiResourceOrgPref
Concurrent SchedulingenableOverbookingOrgPref
Operating Hours for Service Territory Members for Work Type Groups
Salesforce Scheduler for Health Cloud
Resource Appointment Sharing

Step 2 – Include any customizations done to the product offering should be added to the Codebase (repository). Consider evaluating your customizations around

  1. Sharing settings – OWD and Sharing rules (include groups or roles – if sharing rules are around those)
  2. Custom fields on Scheduler objects
  3. New Picklist values on Scheduler objects
  4. Skills
  5. Custom buttons, actions and links
  6. Changes to page layouts
  7. Flows
  8. Custom components that are added to the flows
  9. Custom classes and triggers
  10. Validation Rules
  11. Experience Cloud
  12. Lightning Out for Guest user on a customer website (endpoint URLs will be different)

Post deployment activities

Include steps that need to be performed for the scheduler solution to work. This will mostly include migrating your data and setting up the users and adding scheduler PSLs. Consider leveraging data loader or an ETL tool for data migrations and ensure data integrity (order of loads) and references are maintained post migration between the records in multiple objects.

Salesforce Foundation Objects
SObjectNameLoad SequenceRelationships to Establish
Profile1
UserRole1
PermissionSet1
PermissionSetGroup2PermissionSet
User2Profile, UserRole
Product1
PermissionSetAssignment3PermissionSet Or PermissionSetGroup, User
Salesforce Scheduler CORE Objects
SObjectNameLoad SequenceRelationships to Establish
Skill1Can also be migrated as Metadata (So ensure you are NOT duplicating this step)
SkillRequirement2Skill
Holiday1
Operating Hours1
Operating Hours Holiday2
Work Type Group1
Service Territory2Operating Hours
Work Type2Operating Hours
Work Type Group Member3Work Type Group, Work Type
Service Territory Work Type3Service Territory, Work Type
Service Resource3UserIf using Assets as Service Resource, the order should be after Assets
Service Resource Skill4Service Resource, Skill
Time Slot4Operating Hours, Work Type Group
Service Territory Member4Operating Hours, Service Territory, Service Resource
Appointment Assignment Policy1
Appointment Scheduling Policy2Appointment Assignment Policy
Appointment Topic Time Slot5Work Type Group, Work Type, Time Slot
Salesforce CORE Transactional Objects
SObjectNameLoad SequenceRelationships to Establish
Account3UserOwner of the Account
Parent Account Id should be an additional Step if you manage hierarchy of Accounts
And probably any custom look-ups if you have included Custom Fields
Contact4Account, User
Opportunity5Account, Contact, User
Lead6Account, Contact, Opportunity, UserWhen migrating Converted Leads
Asset5Product, Account, Contact
Salesforce Scheduler Transactional Objects
SObjectNameLoad SequenceRelationships to Establish
Resource Absence4Service Resource
Resource Preference6Service Resource, Related (Account, Lead OR Opportunity)
Shift6Service Resource, Work Type, Appointment Topic TimeSlot
Service Appointment7Service Territory, WorkType, Account, Parent Record (Either Account, Lead OR Opportunity)
Assigned Resource8Service Resource, Service Appointment
Event9Service Appointment, WhatId (Asset, Account OR Opportunity), Owner (Users), WhoID (Lead OR Contact)
Appointment Invitation8Work Type OR Work Type Group, Service Territory
Appointment Invitee9Appointment Invitation, Service Resource

Note – even the scheduling policies and assignment policies have objects (AppointmentSchedulingPolicy and AppointmentAssignmentPolicy) – they can be migrated.

Few best practices to keep in mind

  1. Consider deactivating picklist values that come OOTB if there is NO plan to use them in your solution
  2. If you have hardcoded any IDs in your flows (for defaulting any records like Work Type Group, service territory etc.) – replace with Production IDs wherever appropriate
  3. Turn OFF Rules (Validation, Escalation, Assignment, Workflows, Process builders, Flows, Sharing Rules) to avoid getting errors while performing data loads
  4. Re-calculate Sharing Rules post migration of all data
  5. And Finally explore sfdx-cli data tree import option to load in fewer amount to steps
    1. Make sure the number of records getting loaded are fewer than 200 in a single step (thats the limitation to look for when using the data tree import option with sfdx-cli)
    2. Refer here – https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm#cli_reference_force_data_tree_import

References