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. .
|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.comlevel. 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
technical debtlabel on the issue.
The Systems Label Workflow and Label Description are as follows
technical debtlabel 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
[DELEETE]is also acceptable to prepend to the field name.
Deleted Fieldssection in Salesforce
Approval for Proposed Changes related to Quoting
|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 ApprovalLabel will be added to the issue by the DRI.
Deal Desk::ApprovedLabel to the issue. If no other approval is required, systems can move forward with work.
Deal Desk::Need More InformationLabel to the issue. Deal Desk will partner with Issue DRI to identify alternative solutions.
Deal Desk::RejectedLabel 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 ApprovalLabel will be added to the issue by the DRI.
Channel Ops::ApprovedLabel to issue. If no other approval is required, systems can move forward with work.
Channel Ops::Need More InformationLabel to the issue. Channel Ops will partner with Issue DRI to identify alternative solution.
Channel Ops::RejectedLabel 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:
Change Managment Steps:
git checkout -b "SalesSystems-158".
SFDX: Deploy Source To Orgon the changed classes, triggers or pages.
SFDX: Retrieve Source From Orgon the changed objects or metadata.
git statusto 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-158and push to production.
git checkout masterthen
git pull. Always be pulling!
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 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 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.
Combining the two axis above results in the below priority matrix.
|Peer Review||Peer Reviews are performed by a peer of the change requestor or developer and are intended to identify any potential issues with the planned change or change process.
Note: The peer review process was established to mitigate the risk of the lack of segregation of duties between developer and implementer. The review provides comfort that changes to the production environment are valid.
|Business System Architect||Approval by Business System Architect(or delegate)||Yes||Yes||Yes|
|Business Approval (Typically BI and EA only)||Approval by Business Stakeholder that is responsible for the particular business tool or process which is impacted by the requested change.||Yes||Yes||Yes|
|Director of Sales Systems||The Head of IT must approve all changes made during blackout periods||No||Yes||Yes|
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.
technical debtlabel to the issue.
Sandbox Refresh Checklistfor 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 @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
|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. Must rebuild
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||3/11/2021 10:06 AM||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 Restrictionstable below. Please consult both while completing any data uploads.
Data Upload Training & Setupsection 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.|
|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|