Sales Systems

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

Maintained by:

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
• Priority Matrix
  • Impact
  • Urgency
  • Priority
• Approval Matrix
• Salesforce specific policies and actions
  • Salesforce password policies
  • Installed Package Removal Process
  • Sandbox refreshes
    • How to request a sandbox refresh for a personal sandbox
    • Refresh process for sandboxes maintained as part of the SDLC process
      • Refresh cadence
  • Data, Data Uploads & Permissions
    • Data Upload Permissions
    • Data Upload 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
   • If this issue removes any existing functionality, or requires any components to be deprecated, please include the technical debt label on the issue.
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 in the systems board are automatically tagged and any existing issues related to sales systems are tagged with this label
   • Issues awaiting for information from the requester, needs more clarity in requirements, no milestone and not assigned to systems team member yet
   • Issues that are outside the parameters of an initiative, cannot be combined with current functionality and this issue will be closed
   • Issues that are acknowledged (in review), gathering requirements, no milestone and not assigned to systems team member
   • Issues that are ready to moveforward, slotted to a milestone (not current) & assigned to systems team member's queue
   • Issues that are in the current milestone, assigned to systems team member that are actively to be worked on
   • Issues in current milestone that are near the finish line, needs to be reviewed and demoed to the business owner(s) to sign-off
   • Issues in current milestones, sign-offs given by the business owner that are ready to be deployed by systems team member
   • Issues in the current milestone which are assigned to systems team member which are stalled due to technical difficulties and/or assigned to business owner pending to provide information to the systems member to move forward
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 occurrence 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 inform 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. Add the technical debt label to 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 beginning of the field name. If the field name cannot accommodate a field name that long copy and paste the original name into the description, trim unnecessary 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, work with the Systems team to 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 eligible to be deprecated log into your sandbox and attempt to delete them one by one. Record any connection 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 there 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 deleting fields from the Deleted Fields section in Salesforce

Process Deprecation

• Deprecating a process often includes a change in team behavior as well as updates to any processes. The Systems team is working 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
• Go-To-Market Integrated Environments
• License Usage App Documentation
• Salesforce Configuration Documentation
• Lead source master data set

Salesforce.com Change Management Process

Approval for Proposed Changes related to Quoting

1. All changes that will impact Quoting (ex. creating quotes, creating validation rules, generating quote PDFs, Quote Templates, Approval Module updates) will require approval from Deal Desk and Channel Ops before being pushed to production. The goal is to prevent changes from being pushed to production that could delay the quoting process or create a bottleneck in the quote to cash lifecycle.
2. Approval should be secured in the comments section of the related issue from the Designated Approver outlined below.
3. Additionally, if a change is proposed that could materially impact the quoting experience for Sales teams and is not listed below, please request review from Sr. Manager, Deal Desk in the comments section of the issue.

1. If approval is pending Deal Desk review, Deal Desk::Pending Approval Label will be added to the issue by the DRI.
2. Once Approval is secured, Deal Desk will add Deal Desk::Approved Label to the issue. If no other approval is required, systems can move forward with work.
3. If the proposed change will negatively impact the quoting cycle, Deal Desk will add Deal Desk::Need More Information Label to the issue. Deal Desk will partner with Issue DRI to identify alternative solutions.
4. If the proposed change is not approved, Deal Desk will add Deal Desk::Rejected Label to the issue. An alternative solution must be presented.

Channel Operations and Deal Desk will work closely on all updates related to the quoting process. The purpose is to ensure that a proposed change does not contradict with an existing process that a team member may not be aware of.

1. If approval is pending Channel Ops review, Channel Ops::Pending Approval Label will be added to the issue by the DRI.
2. Once Approval is secured, Channnel Ops will add Channel Ops::Approved Label to issue. If no other approval is required, systems can move forward with work.
3. If the proposed change will negatively impact Channel priorities, Channel Operations will add Channel Ops::Need More Information Label to the issue. Channel Ops will partner with Issue DRI to identify alternative solution.
4. If the proposed change is not approved, Channel Ops will add Channel Ops::Rejected Label to the issue. An alternative solution must be presented.

SLA for Channel Operations & Deal Desk Approvals related to Quoting

Channel Operations and Deal Desk will review each issue with the labels above within 1 business day.

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.
6. You have identified the priority of the request based on our priority matrix, and added the appropriate label: Priority::Low, Priority::Medium, Priority::High

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 Draft:, 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. The Architect (or assigned delegate) will assign the story a Change Management level, based on the scope of the change as defined here.
12. You will then need to document that the appropriate approvals (as defined in the Approval Matrix section below) have been completed in the issue.
13. If the Architect calls for a live demo, schedule the meeting and prep your sandbox to do a run through with the end customer.
14. If the Architect calls for user acceptance testing, make sure the assigned testers have access to the sandbox where the work was done, and schedule testing.
15. Once the solution passes, the Architect will remove the WIP: status and merge the change.
16. Once merged, package up all relevant files into a Change Set from your Sandbox to Production (or to a Staging instance if the Architect requests it).
17. Name the Change Set the same as the issue/branch: SalesSystems-158 and push to production.
18. 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.
19. Once the Change set validates, ping the Architect to schedule the deployment.
20. After the deployment, perform any post deployment steps such as adding visibility to net new fields.
21. Confirm with the end user that the functionality is working as expected.
22. Create a merge request to our technical documentation adding the new feature or editing the features entry.
23. Before moving to your next task rebase with git checkout master then git pull. Always be pulling!
24. Clone the merged change set that was deployed into production and push and deploy this change set to staging. (Post deploy steps and setup are optionable)

Note: We are continuing to move towards using Salesforce SFDX and GitLab CI/CD Pipelines. Contribute on this issue!

Priority Matrix

Priority for the Sales Systems team is based on two axis, Impact and Urgency. For a detailed breakdown of how these work, review this blog post. Priority is used by the team when planning to identify those stories which have a higher business impact and urgency.

Impact

Impact defines how large of an impact (positive or negative) the change proposed in the issue will make for our business. Impact is classified as High, Medium, and Low.

A change which only affects a single or small set of users should be classified as Low impact, while a change which impacts an entire department would be medium, with Large impact being reserved for OKRs and other company wide initiatives.

Negative impact examples include:

• System level outages preventing access to multiple users (High impact)
• Missing functionality to support a key business process for a group of users (Medium impact)
• A field inaccessible to a single user for reporting needs (Low impact)

Positive impact examples include:

• A business process automation which will result in increased revenue or which supports an OKR (High impact)
• Developing a new tool to support a department's use of Salesforce (Medium impact)
• Automating a single repetitive action to save time for a single user (Low impact)

Urgency

Urgency represents how quickly this change is needed by the business stakeholders. Please note that while the urgency is expressed in relation to a targeted delivery timeframe, the team will not always be able to accommodate the urgency if other higher priority issues are needed for the business. The team does recognize that urgency is relative and can change over time, which would also cause an issue to elevate in priority over time. When this occurs, the team will work with you to reclassify the priority of your issue accordingly during our next sprint planning meeting.

• High urgency issues should be addressed by a known due date in the next 30 calendar days
• Medium urgency issues should be addressed some time in the next 90 days
• Low urgency should be be resolved as capacity allows

Priority

Combining the two axis above results in the below priority matrix.

Approval Matrix

Salesforce specific policies and actions

Salesforce password policies

Persuant with GitLab's best practices for password security, our Salesforce environment requires that users use passwords with at least 12 characters, and that they must not re-use any of their last 24 passwords when resetting their password.

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.
   • Add the technical debt label to the issue.
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.

Sandbox refreshes

How to request a sandbox refresh for a personal sandbox

1. Create an issue for the Sales Systems team by following the instructions above.
2. In the issue description, include the name of the sandbox and the names of any users who need to be granted access to the sandbox.
3. Link the issue to any other issues which are blocked pending the refresh of this environment.

Refresh process for sandboxes maintained as part of the SDLC process

1. The Sales Systems team will have an issue tracked in GitLab with a label of SalesSystems and Sandbox Refresh Checklist for the refresh of each environment with a due date of the refresh date.
2. On the date of the refresh, the assigned Sales Systems team member will kick off the refresh in production. Note: A sandbox refresh can take up to 72 hours to complete.
3. After the refresh completes, the Sales Systems team will complete the following steps to set the environment.

Refresh cadence

Sandboxes which are managed as part of our team's SDLC process will follow a regular refresh schedule, as detailed below.

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 Upload Permissions

• It is important to highlight that the below permission all follow the restrictions as laid out in the Data Upload Restrictions 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 Upload 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
  • If you prefer video instructions on how to install Data Loader you can watch this installation video which summarizes the process for windows (The process is the same for Macs)