The Importance of Knowledge Transfer
Are you a Salesforce admin inheriting an org from someone else? Or maybe you’re a developer newly hired into an org without any clue about its business processes or technical structure? Perhaps you’re on the other side—an admin or manager handing over responsibilities to a new team. Knowledge transfer (KT) is more than a handoff; it’s the foundation for ensuring continuity, clarity, and efficiency in managing a Salesforce org. Crafting a thorough KT document helps track critical topics and equips new team members with the insights they need to support the org effectively.
The Content of Knowledge Transfer Document
Here’s your ultimate guide to structuring Salesforce knowledge transfer:
1. Company Overview
Understanding the company is the first step to grasping how Salesforce fits into bigger picture. This can include the Industry and Business Model (What does the company do? What products or services does it offer?), Key Goals (How does Salesforce align with the company's objective?), and Culture (briefly touch on norms that may impact how Salesforce is used).
2. Stakeholders and Key Roles
Knowing who's involved is as important as understanding the org. This includes business stakeholders who request and approve features, technical teams responsible for development and maintenance, and support teams managing escalations and cross-functional collaboration. Documenting these roles ensures new team members know who to approach for assistance and fosters collaboration.
3. Service Desk Processes and Tools
Describe how support and communication are handled. Do stakeholders submit requests via email, chat, or ticketing systems like JIRA or ServiceNow? What's the process when a case is logged - are there specific SLAs, case statuses, or escalation paths? Clarity on these processes helps the new team member hit the ground running.
4. Overview of the Salesforce Org
Provide a high-level overview of what the Salesforce org is doing for the business. Is it primarily used for sales, service, customer portal, or marketing? Which clouds are included? This section should also touch on the size and scope of the org, such as the number of users, types of licenses, and any unique configurations.
5. Data Model and Automations
Dive into the heart of the system: the data model. Detail the key objects in use, their relationships and critical fields. Highlight any customizations, such as fields, formula logic, or record types. Automations must also be discussed - whether they're record-triggered flows, Apex triggers, or manual actions triggered by users.
6. Security
It is another high-value topic. Include the different profiles and roles that are important when configuring a user, how records are shared via org-wide default and sharing rules, and who can access records and what actions they are permitted to perform - via permission sets or permission set groups.
7. Reports and Dashboards
Explain how reporting is structured. Detail how reports and dashboards are organized into folders, and mention whether a naming convention exists to maintain consistency. Highlight key reports or dashboards critical for the business. Specify who owns these resources, who can access them, and whether sharing settings or folder permissions are in place. If possible, include tips for troubleshooting common report or dashboard issues, such as missing data or broken filters.
8. Scheduled and Batch Processes
Every Salesforce org has processes running in the background - scheduled flows, or Apex jobs. Discuss each process, what it does, and when it runs. Include any potential pitfalls or edge cases, like how to handle failures or missed schedules.
9. Installed Packages
Even though managed packages come with their own support, it's essential to document the installed packages, their purpose, and any unique considerations. For example, are there specific steps for updating or uninstalling a package?
10. Integrated Systems
Integrations are most often the most complex part of a Salesforce org. This section should map out all connected systems - such as SAP, NetSuite, or marketing tools - detailing how they interact with Salesforce. Include information such as API endpoints, credentials, monitoring, and troubleshooting steps for common integration failures. Also, list the key contacts for external teams managing these systems. Include the integration or context user for each system.
11. Environments
Development and deployment require their own level of KT. List all the environments in use - developer sandboxes, UAT, staging, and production - and their purposes, when to use, and who manages each of them. If there are rules for using higher environments (e.g. don't overwrite specific configurations, retain disabling email deliverability) that the developers must be cautious, note them.
12. Release Process
How does the team move changes from one environment to another? Are they using tools like Change Sets, or DevOps solutions such as Copado and Gearset? What approvals or testing protocols are required? If there's a different process for hotfix vs. scheduled releases, explain it here. The goal is to equip new team members to manage deployments confidently and ensure a smooth transition during deployments.
13. Sandbox Refresh Process
Refreshing sandboxes can be routine, but it comes with a checklist. Include the steps to follow before and after a refresh, such as backing up critical data, updating SSO configurations, and re-establishing integrations by checking endpoints or user credentials. This proactive step avoids headaches and ensures smooth continuity.
14. Data Management and Loading
Outline any processes for managing data - loading, archiving, or deleting records. If there are tools like Data Loader or Data Import Wizard that are preferred, mention them. This section should also highlight any approval requirements or precautions for bulk updates.
15. Coding Standards
For developers, this section is vital. Clear coding standards ensure consistency and maintainability within the org. Developers should follow naming conventions, optimize code for bulk safety and governor limits, and include comments for clarity. Version control processes and tools like Git should be outlined, alongside best practices like avoiding hardcoding and using static code analysis for quality assurance.
16. Custom Setting and Metadata
Don't overlook the role of custom settings and custom metadata. It is useful for configuring key processes in Salesforce. Each setting should be documented with its purpose, critical values to avoid changing, and examples of usage in automations and integrations. This helps new team members understand their impact and handle changes with caution.
17. Technical Architecture
Wrap it up with a diagram of the org's architecture. Show how Salesforce interacts with other systems, including any middleware, APIs, or external databases. A visual representation helps new team members grasp the big picture quickly.
Conclusion
A well-documented knowledge transfer promotes continuity, streamlines onboarding, and minimizes disruptions. This guide empowers your team to navigate changes in resources or project scope with ease. By providing clarity on processes and encouraging questions, it helps new team members build confidence, ensuring smooth transitions and efficient management of the org.
0 Comments