Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Sales Systems

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

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. .

Role Expertise
Business Systems Architect Project lead in charge of gathering business requirements from customers and developing them into technical specifications.
Business Systems Administrator Business analyst experienced in Salesforce.com platform configuration, process automation, and business workflows.
Business Systems Engineer Software engineer experienced in Salesforce.com platform APEX development, API based integrations, and the software development life cycle.

Technical Documentation

Working with us

How We Work

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

    The Systems Label Workflow

    • Sales Systems 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
    • Need More Information Issues awaiting for information from the requester, needs more clarity in requirements, no milestone and not assigned to systems team member yet
    • Out Of Scope Issues that are outside the parameters of an initiative, cannot be combined with current functionality and this issue will be closed
    • Ready For Assignment Issues that have completed requirements gathering and been accepted, no milestone and not assigned to systems team member
    • Assigned Issues that are ready to moveforward, slotted to a milestone (not current) & assigned to systems team member's queue
    • Build Issues that are in the current milestone, assigned to systems team member that are actively to be worked on
    • Ready To Business Owner Review Issues in current milestone that are near the finish line, needs to be reviewed and demoed to the business owner(s) to sign-off
    • Ready To Deploy Issues in current milestones, sign-offs given by the business owner that are ready to be deployed by systems team member
    • Blocked 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

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:

Positive impact examples include:

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.

Priority

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

Impact /
Urgency		 High Medium Low
High Priority::High Priority::High Priority::Medium
Medium Priority::High Priority::Medium Priority::Low
Low Priority::Medium Priority::Low Priority::Low

Salesforce.com Change Management Processes and SDLC (Software Development Life Cycle)

Changes to Salesforce.com come in a variety of formats but all of them will feature the following change managment controls:

  1. All changes will start with an GitLab Issue defining the ask or problem, and capturing additional decisions and business requirements.
  2. All changes will be developed and tested in a Salesforce Sandbox environment before being deployed or replicated in production.
  3. All changes will be require Business DRI (the requestor) to sign off on the related GitLab Issue once ready and determine a deploy window.
  4. All changes will be be reviewed by the Business DRI once deployed or replicated in production.

In addition, these common types of changes feature additional controls:

Changes that contain Salesforce.com Fields, Workflows, Validation Rules, or other non-code Configuration.

  1. These changes will always use a Salesforce.com Changeset that will be linked to the related issue.
  2. The team member who uploards the change set shall ask a different team member to review and deploy the change. (No Self Deploys).

Changes that contain Salesforce.com Apex Code, Apex Triggers, or Visualforce Pages:

  1. These changes will require the creation of a Merge Request to our SFDC source repository as instructed below.
  2. These changes will require a code review by at least 1 other Business Systems Engineer before being marked as ready to merge.
  3. These changes will always use a Salesforce.com Changeset to deploy that will be linked to the related issue.
  4. The team member who uploards the change set shall ask a different team member to review and deploy the change. (No Self Deploys).

Changes that cannot or are impractical to use a Change Sets (Field Level Security, Sharing Rules, Layout Changes and Assignments):

  1. These changes will need a special deploy window for the changes to be made by hand. Please coordinate with the Business DRI.

Destructive Changes to Salesforce Fields Configration

  1. These should follow our Field and Process deprecation outlined below.

Destructive Changes to Salesforce Code

  1. These changes require sign off from the Senior Director of Sales Systems.
  2. These changes will be done via a Salesforce.com Workbench as a destructive deploy.

Special Approvals

Please seek explicite and documented approval from the Senior Director of Sales Systems for any of the non-standard situations:

  1. A deploy during a designated black out period.
  2. The need to self deploy a non-invasive change.
  3. The need to create a non-invasive formula field in production for time sensitive triage of a critical issue.

These changes would be classified as a CMT: Emergency Change. Any issue where this occurs should be flagged with this label for future compliance review.

  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.
Change Designated Appover Back Up Approver
Approval Module Updates (Discounts, Payment Terms, Approval Structure/Hierarchy, Approval Notifications, Override Functions) Sr. Manager, Deal Desk Manager, Deal Desk
Channel Quote Approval Module Updates (Validation Rule changes, Discount Thresholds, Approval Structure/Hierarchy, Notifications) Manager, Channel Operations Manager, Deal Desk Sr. Manager, Deal Desk Manager, Partner Ops/Alliances
SuperSonics Logic Updates Sr. Manager, Deal Desk Manager, Deal Desk
Smart Templates Gate Logic Manager, Deal Desk Sr. Manger, Deal Desk
Proposed Validation Rules (Ex. "X" Field is Mandatory on all quote objects, if "X" is blank, user cannot move forward with quote. Sr. Manager, Deal Desk & Manager, Deal Desk Manager, Deal Desk
Quote Templates / Docusign Order Forms Manager, Deal Desk Sr. Manager, Deal Desk
Quoting Workflow Changes (Ex. Updating Button Behavior (Edit Quote vs Maintain Quote), removing fields or permissions) Sr. Manager, Deal Desk Manager, Deal Desk
  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.

Salesforce Specific Processes, Policies and Controls

Change classifications

Due to the nature of changes in Salesforce, all the changes above are classified as a CMT: Comprehensive Change for auditing and compliance purposes, unless otherwise noted. In order to not overload this tag with all issues which are addressed by the Systems team, we do not tag issues with this tag at this time.

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.

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 step Owner To be completed by Environments Action steps
Reconnect RingLead user @ksavage @ksavage/@rrosu STAGING 1. Login to RingLead.
2. Locate the SFDC connections page.
3. Authenticate with the RingLead Integration user using the user password for this account in the production org (stored in 1Password).
Disable Scheduled Apex Jobs @sheelaviswanathan @sheelaviswanathan @mclyne    
Disable Outbound Messages or point them to QA server endpoints @sheelaviswanathan @sheelaviswanathan @mclyne    
Reconfigure External Web Service calls for a non-production environment @sheelaviswanathan @sheelaviswanathan @mclyne    
Disable Analytic Snapshots [ If any ] @sheelaviswanathan @sheelaviswanathan @mclyne    
Get the new Sandbox Org ID and instance Id if required @sheelaviswanathan @sheelaviswanathan @mclyne    
Remove the email suffix for required users to send email with new sandbox link

Required Users in Staging Sandbox

jbren
jpetr
msnow
mclyn
lscho
svisw		 @sheelaviswanathan @sheelaviswanathan @mclyne    
Create any required users who don't exist in Production @sheelaviswanathan @sheelaviswanathan @mclyne    
Regenerate (or completely disable) Inbound Email Services @sheelaviswanathan @sheelaviswanathan @mclyne    
Delete / modify entries in Remote Site Settings if you don't want to perform certain callouts. @sheelaviswanathan @sheelaviswanathan @mclyne    
Disable "Big Deal Alert" on Opportunities [ If any] @sheelaviswanathan @sheelaviswanathan @mclyne    
If you have managed packages with API keys ask support teams to regenerate the keys [If Needed] @sheelaviswanathan @sheelaviswanathan @mclyne    
If you have "power users" that will coordinate User Acceptance Testing - create entries in Delegated Administration area so they can "login as" @sheelaviswanathan @sheelaviswanathan @mclyne    
Break Email addresses on Contacts, Leads etc. with suffix like it's done for users (if there's any risk of routine communication kicking in for example from workflow email alerts) @sheelaviswanathan @sheelaviswanathan @mclyne    
Disable Weekly Data Export @sheelaviswanathan @sheelaviswanathan @mclyne    
For any sensitive email templates it might be worthwhile to change content (fake logo, big red "TEST ONLY" etc) @sheelaviswanathan @sheelaviswanathan @mclyne    
Disable Marketo sync Marketing Operations Marketing Operations Staging Contact MOPs to disable the SFDC sync (before refresh).
Create and turn on Marketing Operations Marketing Operations Marketing Sandbox/Staging Must create fields for Marketo Sync (Boolean) on Leads and Contacts in staging before reconnecting. This box should be unchecked, but editable by Mops profile and added to page layout for Mops. Mops will need to request Marketo support to set up custom sync before reconnecting.
Re-authenticate Marketo Sync Marketing Operations/Sales Systems Marketing Operations/Sales Systems Staging/Marketo Sandbox Configure connected Oauth App, reconnect sync in Marketo. Mops will need the new OrgID and create a Marketo support ticket to re-map.
Refresh cadence

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

Sandbox name Sandbox type Used for Refresh cadence Last refresh date Next refresh issue
STAGING Full Pre-production org. Used for UAT of Systems issues prior to release to production. Also used for troubleshooting. As needed, up to once per month, minimum once per quarter 2/13/2022 2:26 PM To be provided
SANDBOX Partial Developer integration and testing org. As needed, up to once per month, minimum once per quarter 6/18/2021 3:14 PM To be provided

Data, Data Uploads & Permissions

Data Upload Permissions

Individuals / Groups Data Upload Permissions
System Admininistrators System Admins have the ability to update any and all fields within Salesforce. They should only be updating the data with an understanding of the impacts downstream such as cascading field updates, APEX code runs, compensation implementations etc.
Sales Operations Members of the Sales Operations Team may complete any data uploads to fields that they can update on their own UIs
Customer Success Operations Members of the Customer Success Operations Team may complete any data uploads to fields that solely impact the Customer Succes organization and their wholly owned processes
Channel Operations Members of the Channel Operations Team may complete any data uploads to fields that solely impact the Channel and their wholly owned processes
Marketing Operations Members of the Marketing Operations Team may complete any data uploads to fields that solely impact the Marketing Team and their wholly owned processes. Prior to completing the uploads though they must inform a member of the Sales Systems team to ensure the fields that they are updating do not cause any cascading updates in Salesforce. Additionally since Marketo and Salesforce are tighly integrated it is encouraged that Marketing Ops also coordinates with the Marketo System Owner to help limit any issues with the integration, API usage etc.

Data Upload Restrictions

Data Data Restrictions
Compensation Data No Compensation data may be updated without first consulting the compensation team and the leadership of the Sales Systems Teams or the Sales Operations Teams
Revenue Data No Revenue fields may be updated without first consulting the leadership of the Sales Systems Teams or the Sales Operations Teams
Closed Opportunity Fields No updates to Opportunity Fields on any Closed Oportunities can be completed without consulting the leadership of the Sales Systems Teams or the Sales Operations Teams
Any Deletions No mass data deletions may be completed without first consulting the leadership of the Sales Systems Teams or the Sales Operations Teams

Data Upload Training & Setup

SFDC Development Guidelines

Before beginning work, make sure:

  1. You have a fully setup local SFDC Dev Environment.
  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)

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.

Field & Process Deprecation

Field Deprecation

Process Deprecation

Deactivate Service User

Sales System's journey with CI/CD using GitLab and Salesforce

We have begun the journey of further leveraging our own GitLab tool by creating our first pipeline for our own Salesforce environment!

Our own pipeline is based on the great work done by @mayanktahil and @francispotter: the SFDC CI/CD templates. If you are interested in more information about this project and want to see it in action, check out Salesforce Development with GitLab and Accelerate DevOps with GitLab and Salesforce

With this comes some change, as we are now more stricly enforcing compliance controls by limiting manual changes into the STAGING org.

Effective 2/16/2022, the following methods are the only approved way to deploy to STAGING.

Our CI/CD template

Our own version of this CI/CD template can be found here. It is a simplified version, to allow us to iterate.

This template removes the capabilities to use Scratch Orgs in favor of using an Org-based deployment model. The model used by this CI/CD file has a single environment configured, denoted as 'STAGING'. The deployment script also limits deployments only to ApexClasses, ApexTriggers, ApexPage, and ApexComponents stored in the root source directory.

The pipeline performs the following action:

Benefits of the pipeline

What's next?

We are beginning to explore using Sandbox Source Tracking, a feature Salesforce released last year to enable easy export of configuration changes from a developer environment into source control.

This tool will enable our admins to track complex changes to their developer orgs and easily check these into source control.

Once we do so, we can expand our pipeline to include these objects in our pipeline in STAGING. This will allow us to validate administrative changes such as field renames, picklist value changes, validation rules, workflow, or flows, and deploy them quickly to STAGING. As this removes the manual step for admins to build change sets from their environments into STAGING, it will save them time to focus on other things.

After this, our next goal will be to see if we want to start automating deployments to STAGING once an MR is merged. This will only save us a click, but is an important step for us as a team to become comfortable with using the process of automated deployments into our STAGING environment.

Open in Web IDE View source