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.
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. |
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 providestechnical debt label on the issue.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 may or may not be assigned to milestone and assigned to the DRI and/or systems team member
Issues that are outside the parameters of an initiative, cannot be combined with current functionality and this issue will be closed
Issues that have completed requirements gathering and been accepted, no milestone and not assigned to systems team member
Issues that are ready to moveforward to be worked on, slotted to a milestone & assigned to systems team member's queue
Issues that are in the current milestone, assigned to systems team member that are actively 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 forwardSales-Support Slack ChannelIn order to deploy & close an issue the checklist below has to be signed off :
SalesSystems::Deployed - # GitLab Labeldefinition of done. The Business DRI will add evidence in the issue or in few scenarios the systems team member will be providing the evidence for the business DRI to confirm in the issue.| Team / Lane | Main Approver | Backup Approver | |—————————–|————————————————————–|—————————————————————–| | QTC | Jesse Rabbits - Director, Quote to Cash | James Harrison - Senior Director, Sales Operations | | Territory Management | Melia Vilain - Senior Manager, Sales Strategy | Jake Bielecki - VP, Sales Strategy & Analytics | | Channel Operations | Colleen Farris - Senior Director, Sales Operations | David Hong - VP of Field Operations | | Customer Success Operations | Jeff Beaumont - Senior Director, Customer Success Operations | David Hong - VP of Field Operations | | Sales Operations | Katrina Gavalas - Director, Sales Operations | James Harrison - Senior Director, Sales Operations | | Marketing Operations | Amy Waller - Senior Manager, Marketing Operations | Christine Lee - Senior Director, Marketing Strategy & Platforms | | Sales Dev Operations | Ramona Elliott - Director, Sales Development Operations | Jean-Baptiste Larramendy - VP, Sales Development | | Sales Compensation | Lisa Puzar - Senior Manager, Sales Commissions | James Harrison - Senior Director, Sales Operations | | Legal | Rob Nalen - VP, Legal Operations | Robin Schulman - Chief Legal Officer |
| Main Approver |Backup Approver (if Jack Brennan or Sheela Viswanathan are unavailable) | Backup Approver (if Jack Brennan or Sheela Viswanathan and Al Champagne are unavailable) | |—————————–|————————————————————–|—————————————————————–| | Jack Brennan - Senior Director, Sales Systems or Sheela Viswanathan - Senior Manager, Sales Systems |Al Champagne - Senior Director, Enterprise Applications | Nabitha Rao - VP, IT |
SalesSystems::Deployed - # GitLab Label :- Once the issue has been deployed, the issue should be tagged with one of the following deploy label following the SDLC - Software Development Life Cycle by the sales systems team member assigned to the issue.SalesSystems::Deployed - 2 - Configuration Change OR SalesSystems::Deployed - 3 - Code Change the systems member assigned to the issue should add the screenshot of the change set.Before a milestone can be closed, the following checks are performed by Sales Systems leadership:
Changes to Salesforce.com come in a variety of formats but all of them will feature the following change managment controls:
We have defined the following ending Label stages for the Sales Systems workflow. Please see the label name as well as SDLC expectations:
Label: SalesSystems::Deployed - 0 - No Changes
Description: This issue is completed. There was no setting, configuration or code change to SFDC. No Sign-off Needed, No Change Set Used.
Label: SalesSystems::Deployed - 1 - Settings Change
Description: This issue is completed. There was a setting change. Sign-off is required, No Change Set Used.
Label: SalesSystems::Deployed - 2 - Configuration Change
Description: This issue is completed. There was a configuration change. Sign-off Required, Change Set screenshot required.
Label: SalesSystems::Deployed - 3 - Code Change
Description: This issue is completed. There was a code change. Sign-off Required, Change Set Screenshot required, Approved and attached MR required.
Before a Milestone is closed perform the following steps:
Please seek explicite and documented approval from the Senior Director of Sales Systems for any of the non-standard situations:
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.
Any changes related to the following fields must have direct approval from the Senior Director of Sales Systems:
| 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 |
Deal Desk::Pending Approval Label will be added to the issue by the DRI.Deal Desk::Approved Label to the issue. If no other approval is required, systems can move forward with work.Deal Desk::Need More Information Label to the issue. Deal Desk will partner with Issue DRI to identify alternative solutions.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.
Channel Ops::Pending Approval Label will be added to the issue by the DRI.Channel Ops::Approved Label to issue. If no other approval is required, systems can move forward with work.Channel Ops::Need More Information Label to the issue. Channel Ops will partner with Issue DRI to identify alternative solution.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.
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.
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.
SalesSystems and Sandbox Refresh Checklist for the refresh of each environment with a due date of the refresh date.| 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 | ||
| Disable Outbound Messages or point them to QA server endpoints | @sheelaviswanathan | @sheelaviswanathan | ||
| Reconfigure External Web Service calls for a non-production environment | @sheelaviswanathan | @sheelaviswanathan | ||
| Disable Analytic Snapshots [ If any ] | @sheelaviswanathan | @sheelaviswanathan | ||
| Get the new Sandbox Org ID and instance Id if required | @sheelaviswanathan | @sheelaviswanathan | ||
| 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 | ||
| Create any required users who don't exist in Production | @sheelaviswanathan | @sheelaviswanathan | ||
| Regenerate (or completely disable) Inbound Email Services | @sheelaviswanathan | @sheelaviswanathan | ||
| Delete / modify entries in Remote Site Settings if you don't want to perform certain callouts. | @sheelaviswanathan | @sheelaviswanathan | ||
| Disable "Big Deal Alert" on Opportunities [ If any] | @sheelaviswanathan | @sheelaviswanathan | ||
| If you have managed packages with API keys ask support teams to regenerate the keys [If Needed] | @sheelaviswanathan | @sheelaviswanathan | ||
| If you have "power users" that will coordinate User Acceptance Testing - create entries in Delegated Administration area so they can "login as" | @sheelaviswanathan | @sheelaviswanathan | ||
| 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 | ||
| Disable Weekly Data Export | @sheelaviswanathan | @sheelaviswanathan | ||
| For any sensitive email templates it might be worthwhile to change content (fake logo, big red "TEST ONLY" etc) | @sheelaviswanathan | @sheelaviswanathan | ||
| 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 (Systems Tasks) | Sales Systems | Sales Systems | Staging | Configure connected Oauth App, provide consumer secret, key and new OrgID to Mops. |
| Re-authenticate Marketo Sync (Mops Tasks) | Marketing Operations | Marketing Operations | Marketo Sandbox | Create support ticket to re-map. Once re-map is completed, connect by updating OAuth information. Then, click Login with salesforce > use custom domain > gitlab--staging and login with Marketo Integration details in 1pw vault. Systems may need to provide verification code sent to admin email. Confirm mappings and sync. |
| Setup new DKIM key and add to gitlab.com DNS | Sales Systems | Sales Systems | STAGING | Setup a new DKIM key following the instructions here. Once the key has been published, provide the CNAME and Alternate CNAME values to the Gitlab IT team to add to the DNS for gitlab.com. Once this is done, confirm an email can be sent to an external email address from a Case using the 'Send an Email' feature, and the email is delivered without issue. |
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 | 11/11/2022 | 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 Upload Restrictions table below. Please consult both while completing any data uploads.Data Upload Training & Setup section before being permitted to upload data.| 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 | 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 |
Before beginning work, make sure:
Priority::Low, Priority::Medium, Priority::HighChange Managment Steps:
git pull.git checkout -b "SalesSystems-158".SFDX: Deploy Source To Org on the changed classes, triggers or pages.SFDX: Retrieve Source From Org on the changed objects or metadata.git status to make sure the changed files are the ones you expected.git add [filename] or git add * if you want to add all changed files.git commit -m "Fixing Apex CPU Errors".Draft:, and assign it to the Architect on the project.WIP: status and merge the change.SalesSystems-158 and push to production.git checkout master then git pull. Always be pulling!Installed packages are provided by ISVs ( Independent Software Vendor) who work on the Salesforce platform, and contain the code and configuration for Salesforce which extend the capability of the platform. These are commonly installed and requested by our business partners to extend Salesforce's native capabilities.
Packages come in two flavors, managed or unmanaged. Managed packages are equivalent to signed apps, with self contained source sealed inside of the package. Unmanaged packages are unsigned, and generally contain raw code and configuration.
Generally, vendors either provide managed packages via the Salesforce AppExchange, or via direct installation from their repository. Unmanaged packages generally are provided by the vendor, and may contain raw source or configuration which needs to be manually installed. Note, any code provided the GitLab remains the IP of the vendor provided, unless specific accommodations are provided (such as if we contract with a vendor to extend their base functionality). Because of these additional considerations, unmanaged packages require additional steps to be completed as part of the installation process.
Any package code is the responsibility of the vendor who produced it to support and troubleshoot. If issues are encountered with the functionality, please contact the vendor in question to troubleshoot. If there are changes recommended by the vendor to our environment, log an issue with Systems to track any changes which are requested by the vendor using one of the two processes below.
We (Sales Systems) reserve the right to remove or uninstall managed or unmanaged code at any time, if this package is determined to cause issues related to system performance or limitations.
If we are accepting unmanaged code or config, we will choose whether to accept these on a case-by-case basis. Unmanaged packages offer significant risk and resource utilization over our managed code. Our goal is always to accept managed packages from vendors.
The uninstall process is the same regardless of whether a package is managed or unmanaged.
technical debt label to the issue.technical debt label to the issue.[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 [DELETE] is also acceptable to prepend to the field name.Deleted Fields section in SalesforceWe 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 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:
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.