Sales Systems

1. You are here:
2. Handbook
3. Sales
4. Field Operations
5. Sales Systems

Maintained by:

Jack Brennan

@jbrennan1

On this page

• Sales Systems Charter
• Team Skill Sets
• Working with us
• How We Work
  • Steps to getting help from Sales Systems
  • Field & Process Deprecation
    • Field Deprecation
    • Process Deprecation
    • Deactivate Service User
• Technical Documentation
• Salesforce.com Change Management Process
• Salesforce.com Installed Package Removal Process
• Salesforce Data, Data Uploads & Permissions
  • Data Uplod Permissions
  • Data Uplod Restrictions
  • Data Upload Training & Setup

Sales Systems Charter

Sales Systems exists to support the GitLab field organization by providing reliable, scalable, and intuitive technology platforms for everyday use. Primarily working on Salesforce.com and its related business systems, our goal is to constantly deliver value in the form of features to our end users. We also act as the connective tissue between business and technology, gathering requirements from our internal customers, designing the technical specifications and executing on the delivery of the solution.

Team Skill Sets

Below is a list of the different technical skill sets found on the Sales System team. Note: A Sales Systems team member might be using a mix of the following skills sets at any one time.

Working with us

• Sales System Agile Board
• Sales Systems Project
• Salesforce.com APEX repository

How We Work

• The Sales Systems team works in two week sprints/iterations which are tracked as Milestones at the GitLab.com level. This aligns the Sale Systems team with how many of our business partners operate but also takes advantage of one of the solutions that Gitlab provides
• The Systems team strives to emulate the principles below in planning and executing on our milestones as we believe it most effectively aligns our team with Gitlab's Values
  • "Start less, finish more"
  • "Reduce Issue Churn"

Steps to getting help from Sales Systems

1. Create an issue in our project, making sure to provide detailed business requirements for the ask or problem. Please leave assignee blank
2. In order to align our working style with the Labels, the Systems team prioritizes working on issues in the order as they get added & the issues get labelled accordingly

3. The Systems Label Workflow and Label Description are as follows

   

   • New Issues that are created will be automatically tagged and any existing issues related to sales systems gets tagged in this label
   • Issues that are acknowledged(in review)that are not slotted into the next milestones and not assigned to systems team members
   • Issues waiting for more information from the requester, no milestone and not assigned to systems team member
   • Issues that are out of scope or cannot be combined with current functionality and this issue will be closed
   • Issues in current milestone, assigned to systems team member worked on
   • Issues in current milestones that are near the finish line and needs to be reviewed/demoed
   • Issues in current milestones that are ready to deploy in production
   • Issues in the current milestone which are assigned to systems team member which are stalled and blocked due to technical difficulties
4. Please review the status of any issue on our agile board.
5. If there is a severity impacting the flow of business (i.e. No one can make a quote, No accounts are being created, Opportunities cannot be closed Won) follow the process as described above as well as share the issues in the Sales-Support Slack Channel

Field & Process Deprecation

• Since field & process deprecation is as common an occurance as the creation it is important that the system team implements a repeatable process that we can leverage when deprecating any fields pr processes.

Field Deprecation

• This process is most often used by the systems team. If you have or are aware of a field in Salesforce that is no longer needed, please infom the Sales Systems team by following the process outlined in getting help from the sales systems team
  1. Open an issue listing out all of the fields that we are investigating to deprecate. Be sure to include the field name, field API name and the object that the field is associated with in a table in the description of the issue.
  2. Alert the data team to the upcoming field deprecation by tagging them on the issue.
  3. Alert all relevant partner teams (Marketing Ops, Sales Ops, Finance Ops etc.) as needed
  4. Prepend [DEPRECATE] to the begining of the field name. If the field name cannot accomadate a field name that long copy and paste the original name into the description, trim unneccessary characters from the name and try again. For this reason [DELEETE] is also acceptable to prepend to the field name.
  5. In Visual Studio Code, pull from master and perform a scan for each of the API names in the issue. If the field is used, investigate if the code can be updated as to not include this field.
  6. If code is updated in the previous step prepare a merge request and relate it to the issue.
  7. If your sandbox is out of date, refresh it so that any recent edits are included in the next step.
  8. Push any updated code to your sandbox (if applicable) and start a change set.
  9. For all fields that are still eligable to be deprecated log into your sandbox and attempt to delete them one by one. Record any conenction between any fields and any field updates, workflow rules, validation rules etc. (Reports, Report Types etc can be ignored in this step)
  10. Investigate any connections found in the previous steps and if the field can still be deleted.
  11. For all fields that cannot be deleted
  • Link the investigation issue to the investigated field by pasting the Gitlab Issue Link in the fields description.
  • Assign someone as an owner of the field in Salesforce
    1. For all fields that can be deleted
  • List them out on a final comment on the issue
  • Update the due date of the issue to the date they will be deleted
  • Confirm that their are no issues with the tagged related teams
  • Validate any change sets with updated automations (if applicable) before the issue due date
  • On the issue due date deploy any change sets and delete the fields from production. If possible allow for a 1 day lag time between field deletion and delting fields from the Deleted Fields section in Salesforce

Process Deprecation

• Deprecating aprocess often includes a change in team behavior as well as updates to any processes. The Systems team is wokring on detailed documentation to address these changes and more info will be coming soon!

Deactivate Service User

• This deactivation process is made to deactivate service user profiles. Service accounts are accounts that are used as integration Users, Connection users etc., in order to deactivate the service user account follow the template. Please note deactivating standard users will be done by Sales Operations.

Technical Documentation

• Go-To-Market Technical Documentation
• License Usage App Documentation
• Salesforce Configuration Documentation

Salesforce.com Change Management Process

Before beginning work, make sure:

1. You have a fully setup local SFDC Dev Environment.
   • Visual Studio Code
   • Salesforce Trailhead: Setting up your VS Code
2. You have access to a personal SFDC Dev Sandbox.
3. Your SFDC Dev Environment is correctly pointed at your SFDC Dev Sandbox
4. You have cloned our Git repository into your local Sandbox working directory.
5. You are working from a GitLab issue with clear technical specifications that deliver on the agreed business requirements.

Change Managment Steps:

1. Make sure you start on branch master and git pull.
2. Create a new branch, giving it a name that ties back to the issue: git checkout -b "SalesSystems-158".
3. If you are writing code, frequently push your changes to your sandbox using and SFDX: Deploy Source To Org on the changed classes, triggers or pages.
4. If you are editing configuration, frequently pull down your changes to your local environment using SFDX: Retrieve Source From Org on the changed objects or metadata.
5. Make sure to write and run a unit test for code, and for both code and config, test the changes by hand in the SFDC user interface.
6. When you feel your iteration is complete run git status to make sure the changed files are the ones you expected.
7. Add in the files you wish to commit with git add [filename] or git add * if you want to add all changed files.
8. Commit your changes with a relevant message: git commit -m "Fixing Apex CPU Errors".
9. Using the link provided by GitLab, open a merge request, make it a WIP:, and assign it to the Architect on the project.
10. Comment on the related issue with an @ to the project's Architect for review, providing a link to the merge request. (this automatically links the merge request to the issue)
11. If the Architect calls for a live demo, schedule the meeting and prep your sandbox to do a run through with the end customer.
12. If the Architect calls for user acceptence testing, make sure the assigned testers have access to the sandbox where the work was done, and schedule testing.
13. Once the solution passes, the Architect will remove the WIP: status and merge the change.
14. Once merged, package up all relavent files into a Change Set from your Sandbox to Production (or to a Staging instance if the Architect requests it).
15. Name the Change Set the same as the issue/branch: SalesSystems-158 and push to production.
16. Once the Change Set arrives in production, validate it. If there are any errors, go back to step 3. If steps 3, 4, and 5 are followed errors at validation should be rare.
17. Once the Change set validates, ping the Architect to schedule the deployment.
18. After the deployment, perform any post deployment steps such as adding visibility to net new fields.
19. Confirm with the end user that the functionality is working as expected.
20. Create a merge request to our technical documentation adding the new feature or editing the features entry.
21. Before moving to your next task rebase with git checkout master then git pull. Always be pulling!

Note: We are continuing to move towards using Salesforce SFDX and GitLab CI/CD Pipelines

Salesforce.com Installed Package Removal Process

1. Identify the package and what reason(s) you may think it can be removed.
2. Perform initial research on what the packages original intent may have been and identify who owns/owned the use of the functionality.
   • GitLab's Tech Stack Google Sheet is a great place to check for this information and can be found here
3. Open an issue with the owner to investigate further. In this discussion, obtain confirmation on whether or not it may be removed.
4. If confirmed to move forward, test by removing the package from the sandbox.
5. If successfully removed from sandbox, announce the intent to move forward in removing.
6. Document any relevant information about the package.
   • An example of this could be SFDC fields that are part of the package.
7. Remove the package from production, update the issue and close out.

Salesforce Data, Data Uploads & Permissions

• Salesforce is one of the key systems that our business relies on and as such the data and its accuracy is extremly important to the business. As such we strive to find the balance between ability to update the data within Saleforce and maintaining its integrity. While we do implement systems that strive to maintain and ensure that the data within Salesforce is correct we understand that sometimes the data is incorrect as business requirements change and updates to the data are needed. As such the below aims to outline the individuals who are allowed to mass update the data within Salesforce and the corresponding fields that are permitted to be updated as well as the fields that are restricted from being updated.

Data Uplod Permissions

• It is important to highlight that the below permission all follow the restrictions as laid out in the Data Upload Restructions table below. Please consult both while completing any data uploads.
• Any data uploads that impact more then one organization unit, can only be completed after the notice and approval by all impacted teams. When there is any doubt if a data upload will impact multiple teams a System Administrator should be consulted before completing the data upload.
• All users who wish to upload data using the DataLoader must first complete the requierments in the Data Upload Training & Setup section before being permitted to upload data.
• When informing leadership or other teams of your data load be sure to summarize the fields that are being updated using the field name and API name of the field in order to strive for more efficient communication on the data load process.

Data Uplod Restrictions

• When in doubt if you have permission to update fields in Salesforce using the data upload process reach out to a System Administrator to clarify if your uploads are permitted and have any unintentional impacts.

Data Upload Training & Setup

• Prior to being permitted to utilize the Data Loader all users must review the Data Loader Documentation provided by Salesforce
  • Key Highlights:
    • Data Loader Configuration especially as it pertains to batch size and to working with Null values. This should be reviewed and confirmed prioir to every Data Upload
• In order to install Data Loader follow the Instructions provided by Salesforce