Use the Global Channel Dashboard to view Pipeline Creation, Open Pipeline, and Bookings reports grouped by Partner, Segment, or Region. Other reports within the Global Channel Dashboard include Deal Path, Engagement, Deal Type, Top Channel Deals by IACV, and Deals Registered through the Partner Portal.
For a global view of current and next fiscal quarter channel renewals, click here.
All required team reporting is included above. In the event you need a special report, please open an issue and tag Channel Ops.
SFDC Channel Training Cheat Sheet:Refer to this document for the training video hosted by the Channel Operations team, as well as quick reference "cheats" to help with your Salesforce reporting.
Managing Channel Opportunities
Partners must be an Authorized Partner of GitLab’s in order to sell GitLab products and services. To achieve authorization, partners must have an executed agreement and meet the requirements of the GitLab Partner Program. Unless you are a GitLab partner in the program and in good standing, you may not sell GitLab products and services unless specifically approved on a case-by-case basis by the GitLab partner program team.
Policy and Process
All channel opportunities require a Partner to submit a Deal Registration via the Partner Portal in order to receive programmatic discounts. In the event that a Partner does not submit a Deal Registration (ex: Alliances, GSIs), but it is a Partner Sourced deal, the logic needs to match 'Initial Source = Channel Qualified Lead and Sales Qualified Source = Channel Generated on the opportunity. For more details on the partner deal registration process and program go here.
Note: The Partner Portal is Impartner which has SSO enabled with Vartopia which is the Partner facing Deal Registration system. Managed Services team are 3rd party resources that will help manage administrative processes for Deal Registration.
When a Partner submits a Deal Registration the Managed Services team will handle the initial submission. The submission will trigger the following actions:
Send an email to the Partner acknowledging the Deal Registration has successfully been created
Notify the Managed Services team to review
Create a record in SFDC on the Registration object with all of the details of the Deal Registration.
The Managed Services team will evaluate the Registration, link it to the appropriate Customer Account and Contact in SFDC and then send it to the applicable Channel Manager for approval/denial.
The Channel Managers need to review the deal registration and either approve or deny. It is highly recommended to work with the applicable GitLab Sales Rep prior to taking action.
Although multiple partners can submit a deal registration for an opportunity, only one deal registration can be approved for a specific opportunity. As a reminder, deal registrations are opportunity based and partners cannot register an account.
Before approving or denying the Deal Registration the Channel Manager needs to check to see if an Opportunity already exists.
Click the button at the top of the Deal Registration page:
If an Opportunity already exists then SELECT the applicable one.
If not then select:
If creating new, the applicable details from the Deal Registration will map to the Opportunity and automatically tag it as a Partner Sourced opportunity. Any other system required fields will also need to be filled out. Be sure to update the opportunity owner into the correct sales rep's name, and out of the channel manager's name.
After the Channel Manager either hits SELECT against a current Opportunity OR CREATE NEW, the Deal Registrations needs to either be approved or denied.
Click
DENY: If denying the Deal Reg, the comments will be sent to the Partner along with updating the Deal Registration system and SFDC.
APPROVE: If the Deal Registration is to be approved, then the Channel Manager will be required to select whether or not a Distributor is applicable to the deal if not already stated.
If not, then no Distributor is required to be linked.
If yes, then
needs to be filled out before moving forward.
If approved, then a notification will be sent to the Partner, the Deal Registration system updated, and the Registration status updated to Approved.
When a customer account is created by "User Vartopia" during a deal registration, that customer account should be reassigned to the appropriate sales rep. For more information, click here.
Deal Registration System Status and Information:
Deal Registration details will never override any information that the sales team forecasts on the Opportunity.
There is a Deal Registration ID that can be used to track all Deal Registrations in the system.
A Deal Registration is valid 90 days but can be extended if needed.
All Deal Registrations are now in their own object in SFDC under Registrations. They no longer come in as leads.
DR - Partner: Partner that submitted the Deal Registration
DR - Partner Deal Type:
Resale: Partner is actually transacting the deal on their paper
Referral: Partner is bringing us the lead/opportunity but will either transact direct with GitLab or through another partner
Services Attach: Partner-delivered services provided to the end user related to their use of the GitLab software
DR - Partner Engagement: How the deal was sourced or the value the partner is bringing
Partner Sourced: Partner has either found the original opportunity or it is an upsell to a current customer. If the Initial Source = Channel Qualified Lead or `Sales Qualified Source = Channel Generated', then the deal is Partner Sourced.
*In FY21, the Channel Team use "PIO" instead of Partner Sourced. The definition has been updated for FY22.
Assisted: GitLab-sourced opportunity where the partner assists our sales team in closing the deal
Fulfillment: Partner only processes the order and doesn’t provide additional support to close the deal
Distributor: If the DR - Partner are buying from a GitLab authorized distributor.
Fulfillment Partner: Only applicable if the DR - Partner Deal Type is "Referral" and the deal is being transacted through another partner.
Platform Partner: Customer's platform that GitLab is being deployed.
Influence Partner: Other partners, generally GSIs or alliances that have helped influence a deal.
For more details on Partner Engagement definitions go here.
Rules of Engagement on Channel Deals
Deal registration approval is based upon order of receipt of the registration, qualification of the opportunity, partner ability to deliver in-country/region support, and partner relationship with customer. Final deal registration approval decision will be made by GitLab Channel after discussion with GitLab Sales.
Only one partner can earn a deal registration discount per opportunity. Partners, other than the partner granted the deal registration discount that requests a quote, will receive the fulfillment discount rate.
Any partner opportunity can be a registered deal. These opportunities can be either Partner Sourced, Partner Assist, Partner Fulfilled or Partner Services Attach. Visit Program and Incentive Definitions to learn what deals qualify for each category.
Approved deal registrations have standard 90-day expiration from the date of original approval (Deal Registration extensions beyond the initial 90 days approval are at the sole discretion of GitLab).
GitLab collaborates with partners holding the approved deal registration and is available to support partners throughout the entire sales process.
In the event the engagement is dissolved, the GitLab Sales Rep will generally notify the partner by phone or email. GitLab will reconsider other qualified deal registrations submitted for this deal, in chronological order of submission. If there are no other registration requests submitted, the GitLab sales rep will typically initiate engagement with a reseller of the GitLab sales rep’s choosing.
Quoting Requirements for Channel Deals
Any time a deal is being transacted via the Channel, a GitLab quote is required to be created in SFDC if any pricing is being offered other than MSRP (List Price).
At a minimum, a Draft Proposal needs to be created and provided to the Partner. If a Partner has an approved Deal Registration, then an approved quote needs to be created and provided to that Partner.
Discounted quotes that are not in the system and sent to a Partner are not permitted at this time. This includes providing product and pricing quotes details in email. This applies to all GEO’s and Segments.
Any questions or issues, please reach out to either Channel-Ops or Deal Desk.
Managing Special Cases
Creating MSP Opportunities
A Managed Service Provider (MSP) purchases licenses on behalf of an end user. The MSP will be the owner and manager of the licenses but their customer - the end user - is the one using the licenses. This creates specific needs in GitLab Salesforce opportunities to ensure proper reporting and compensation.
When you have an MSP opportunity, the Sales Reps need to follow these additional steps:
Step 1: The opportunity must be created using the MSP partner account, NOT the potential customer on whose behalf they are purchasing.
Step 2: Change the opportunity owner to the correct Sales Rep that owns the end-user account even though the opportunity is created under the Partner MSP account.
Step 3: Fill out the Partner and Deal Registration Information Section per the following:
DR-Partner: this must list the MSP’s Partner account (same as the opportunity is created under)
DR-Deal type: "MSP"
DR-Engagement: Select applicable answer
If there is an approved Deal Registration, the Partner data will automatically be added when the Deal Registration is linked to the Opportunity. The DR-Engagement will be the only piece that needs to be filled out.
Step 4: When filling out the quote for this opportunity, select the MSP quote template.
Invoice owner: The MSP Partner (same as DR-Partner referenced above).
Special Terms and Notes: Name of the End-user Customer (the MSP owns the licenses on behalf of).
Creating a Service-Attached Opportunity
New Process as of November 3rd 2020
A Service-Attached Deal Registration needs to be created to track when a partner offers their own professional services along with GitLab licenses. This is separate from the Deal Registration for the license sale.
To track the Partner Services, the partner must register the deal on the partner portal.
Next, select the Opportunity that is applicable to the GitLab sales of licenses that the services are being performed for. This GitLab sale opportunity may be open or closed won.
This Services Deal Registration is now attached to the GitLab sale opp. Once linked, the Channel Manager will now need to approve per the Deal Registration by selecting
.
Once approved then a notification will be sent to the Partner, the Deal Registration system updated, and the Registration status updated to Approved.
Rebate payouts will be reported and paid after each GitLab quarter close.
Prior to November 3, 2020
A Service-Attached opportunity is created to track when a partner offers their own professional services along with GitLab licenses. This is separate from the license sale and respective Salesforce opportunity.
To create the opportunity, the partner must register the deal on the partner portal. The opportunity needs to be created for the service-attach opportunity alone. The service-attached opportunity should never be a part of, or added on to the GitLab product sale opportunity.
For proper reporting, ensure that all the correct fields are used to notate that this is a partner service-attached opportunity.
DR - Partner: The partner account providing the services
DR - Partner Deal type: Services Attach
DR - Partner Engagement: N/A
GitLab Sales needs to add the GitLab product sales opportunity as the parent opportunity to the service-attached opportunity.
As the opportunity progresses, use the stages of the opportunity (0 - 7) until the agreement documentation is received that the customer is moving forward. Once the agreement for the Partner Services is completed (i.e. SOW, quote, order form), change the opportunity to Stage: 10-Duplicate.
Multiple-bid Process
For opportunities where there are multiple partners bidding on the same opportunity, it’s important that each partner gets the appropriate pricing for the opportunity.
Deal Path: How the deal is transacted. Values can be Channel, Direct, or Web. Also, includes Referral Ops for Channel.
Deal Reg: Partner submits a Registration for their opportunity via the Partner Portal. For the purposes of this matrix the assumption is the Deal Reg is approved
Initial Source: SFDC Lead value that is populated based on lead source. Will default to CQL when a Partner submits a Deal Reg and an Opportunity does not already exist in the system.
SQS: Who converts/creates the Opportunity in SFDC. Can only be 1 value
DR - Partner Engagement: Partner Value on the deal via the Partner Program definitions. This is manually selected in most cases
Order Type: Customer order designation in SFDC. New First Order or Growth
Use Cases:
#1 and #3
Channel submits Deal Reg and no Opportunity exists in the system. Therefore the Initial source is CQL, and SQS and DR-Partner Engagement default to Channel and Partner Sourced
This applies to both New and Growth orders
#2 and #4- Examples:
AE Creates Opportunity prior to Deal Reg being submitted - CAM to escalate for exception
Opportunity stalled and Channel helps to drive to closure - If channel is simply unsticking an open opp then this is technically Assist. Exceptions can be reviewed
Aged opportunities that are closed and revived due to Channel - Automated clean up with Sales Ops stale Opp policy- Exception: In the event an exception is needed per the scenarios below and exception can be submitted for review and have the ability “override” and restate these are Channel SQS
Default Logic
Deal Reg = True and no Opp Exists then Initial Source = CQL > SQS = Channel, Defaults to Partner Sourced
Alliances: Does not have same logic and will need to be reported separately currently
SFDC Opportunity Source Field Values for Channel
SFDC Opportunity Fields:
Initial Source:
Channel Qualified Lead (CQL): GitLab Channel Partner created and/or qualified the Lead whether they sourced it themselves or GitLab provided the inquiry to them to work
Sales Qualified Source:
Channel: Channel Partner has converted the Lead/CQL to a Qualified Opportunity. This field defaults to Channel when Initial Source = CQL
DR - Deal Engagement:
Partner Sourced: Partner has either found the original opportunity or it is an upsell to a current customer. If the Initial Source = Channel Qualified Lead or Sales Qualified Source = Channel Generated, then the deal is Partner Sourced.
Assist: Partner Assisted Opportunity
Fulfillment: Partner Fulfillment Opportunity
*For additional definition and qualification of Deal Engagement type go here.
The GitLab Partner Program provides partners with set discounts based on their engagement in opportunities (see definitions below) and their partner program track.
Partners are not eligible for discounts on sales or renewals of Bronze / Starter licenses.
GitLab employees can access the discount table here. Partners can find the discount table in the Asset Library on the GitLab Partner Portal.
Partner Sourced Opportunity
A Partner Sourced opportunity is an opportunity where a Partner has either found an original opportunity or is upselling a current customer.
An opportunity can only be Partner Sourced if the Initial Source = Channel Qualified Lead or Sales Qualified Source = Channel Generated.
A Partner Sourced opportunity could be:
An opportunity with new customer to GitLab
An opportunity with a customer/prospect with which GitLab is already engaged, but was not aware of the specific Partner Sourced opportunity
An existing customer upgrade to a higher pricing plan. This could be for a customer that was originally sold by GitLab.
Additional licenses sold, often at the time of renewal. This can also be an increase in size of an existing GitLab sales opportunity.
True-ups to an original partner opportunity.
The opportunity must be new to our sales team or added to an existing sales opportunity, and can be for a new or existing customer.
The partner is expected to collaborate with the GitLab Sales team to jointly close the sale.
For US Public Sector, each unique customer opportunity within a single government program can be Partner Sourced.
For resale, the partner receives an upfront discount that is dependent on the partners track within the GitLab Partner Program.
Referral rebate payments are paid out no later than 45 after the end of each GitLab fiscal quarter.
The determination of Partner Sourced is per the system logic stated above and tracked via Salesforce opportunities.
Partner Assist Opportunity
Any opportunity where the partner assists our sales team in closing the deal.
This assistance may include any or all of the following: a customer demo/POV, an executive introduction meeting, delivery of services, helping with the transaction, financing. Often this is leveraging the partner's incumency.
Partners need to submit a Deal Registration for Partner Assist. Since it is for a GitLab sourced opportunity, it does not qualify to be Partner Sourced, but should be tagged as Partner Assist in Salesforce.
The determination of Partner Assist is at the sales rep & CAM determination and tracked via SFDC opportunities.
Partner Fulfill Opportunity
Any opportunity that was fulfilled by a partner but closed independently via the GitLab sales team.
The partner has only processed the order and didn’t provide any meaningful support to close the deal.
Services Attach Opportunity
Any partner delivered services that are provided to the end user in support of a GitLab deployment.
This will result in a 2.5% upfront discount from the product for resales opportunities and a rebate if partner is not involved in resale.
The resale discount will be administered as an upfront discount from the GitLab license price on the most recent product sale net license price.
This is stackable for up to three (3) independent services engagements over a twelve (12) month period, provided by the partner to a single end user.
The maximum discount or rebate is 7.5% with any combination of upfront or post sales partner branded services.
Partner Services engagements must meet the following partner services engagement deal size minimums to qualify:
1st deal: => $7,500 in services
2nd deal: =>$10,000 in services
3rd deal: => $10,000 in services
Partners must register a Services Attach deal registration and provide proof of performance to qualify for the incentive.
Rebate payments are paid out at the end of each GitLab fiscal quarter.
Rebates and referral fees may require CRO approval.
Services Resale
Partners can earn a program discount for reselling GitLab Professional Services delivered services.
To qualify for the Services discount, the services must be included on the order of a deal registered opportunity.
Incumbency Renewals
Incumbent partners qualify for program renewal discounts. The partners that transacts the most recent sale (IACV) are considered the incumbent
A different partner can earn an incumbency discount only through formal written communications from the customer. This can be provided via email from an authorized representative from the customer.
In some cases, a customer purchased their most recent subscription directly from GitLab, but is directed to a partner for renewal. Partners are encouraged to engage with these customers, but their first renewal of a formerly direct customer will not be discounted for partners.
To earn partner discounts, partners will be required to meet compliance requirements (i.e. in good credit standing, have provided quarterly updates on customer, review within 30 days of renewal, etc).
Tender Offers
Tender offers are ones where the customers are requesting multiple bids for a project.
Each partner bidding should register the deal. Since all partners would be engaged in the sales process and would be creating a bid, all partners qualify for Partner Assist discount (% based on their program track). If the first partner registering the deal was early in with the customer (pre-tender), introduces the opportunity to GitLab, and the appropriate system logic fits, that partner could earn a Partner Sourced discount. If the partner earning the Partner Sourced discount is not awarded the deal, they would not receive additional referral compensation.
Any partner offering services would qualify for Services-Attach incentives in addition to any sales discounts for which they would qualify.
Program Compliance
For partners to transact according to program discounts, they must agree to the GitLab Partner Agreement.
To earn partner discounts, partners will be required to be program compliant.
Non Contracted partners may transact on a one-off basis, only with approval of channel leadership.
Unauthorized Partners
Unauthorized partners are ones that have not signed a GitLab Partner Agreement.
A key goal of the GitLab Channel Program is the success of our authorized partners. We are developing our channel to provide coverage across geos, customer segments and vertical markets. Since the program was just launched in April 2020, we have not onboarded enough partners to support every sales opportunity. As we continue to build out our channel coverage, there will still be a need to utilize one-off, unauthorized partners for specific sales opportunities.
For Developed Regions - Most P0 and many P1 countries. GitLab Sales teams, work with your CAM to identify authorized partners in your region.
GitLab Sales teams should use existing, authorized GitLab partners, including our distributors, whenever possible.
For FY21 Q2 and Q3, one-off partners can provide fulfillment transactions utilizing the Fulfillment contract. Additional instructions for opportunities sold via fulfillment partners are available in the Handbook.
Q4 and beyond - VP approval required for one-off partner requests.
For Developing Regions - GitLab Sales teams, work with your CAM to identify authorized partners in your region.
Use fulfillment contract for one-off partner deals
On a quarterly basis, the Channel team will revisit developing countries to determine if there is a continued need for fulfillment partners, or if we have the necessary coverage with authorized partners.
Partner Program participation sign ups must be initiated by the Partner in the Partner Portal application form which can be found here. In the partner application process, channel partners review the partner contract, including both the resale and referral addenda, review the partner program guide, complete their application form and agree to program terms and conditions. Technology partners are not able to agree to the terms and conditions during the application process.
If an authorized representative of the channel partner accepts the agreement terms, they (or the person entering the application) will need to select “Yes” that they agree to terms on the application form. Once they have agreed, they will automatically be set to “ Authorized” and will get immediate access to the partner portal. At this time, partners will be set up in both Salesforce and the partner portal at Authorized and their track set to Open.
The partner will receive an email confirming the receipt of their application, and applicable Channel Sales or Alliance Manager will receive a New Partner notification email from Partnersupport@gitlab.com notifying there is a new partner applicant in that region. Channel Sales Managers will be notified of each partner application in their regions, whether they agreed to the terms or not.
Upon receiving notification they will be responsible for reviewing the partner’s information and deactivating any inappropriate partners. They will also need to set the Partner Type in Salesforce for newly authorized partners.
For partners that have questions about the contract or need to negotiate terms and conditions, Channel Sales Managers are responsible for working with the partner offline to address questions and come to agreement on program terms. Upon receiving the New Partner Applicant notification email, the applicable Channels Sales Manager needs to complete the following:
Contact the partner and qualify them
If the decision is to move forward with the partner first check to see if a partner account already exists in Salesforce. If it is a duplicate, request for the accounts to be merged by the Channel Operations team. If the decision is to deny the partner then go to step #7.
To start the contracting process click the Legal Request button in SFDC on the partner account record.
Request the appropriate contract addendum (Resale, Referral/Services or both OR MSP OR OTHER). Default should be Resale and Referral/Services.
Once the contract is fully executed and attached to the partner account record in SFDC the following fields need to be updated by the Channel Sales Manager and are required(*) in order to save the account
*Change Partner Status = Authorized
*Select Partner Type
For partners that signed standard contract terms, set Partner Program Status to “New”.
Please update the partner record to be as complete as possible.
For additional information on the Partner Program review here
Once a partner is authorized, each SFDC contact for that partner will automatically receive a message with login credentials to the portal.
Additional partner employees can go to partners.gitlab.com to register. \ Once they are linked to an authorized partner account (they must select the correct account upon registering), they will automatically receive a message with login credentials. If the account is still a Prospect they will not have access until the account has an executed contract and is moved to Authorized.
If the decision is to not move forward with the partner,
Channel Sales Manager needs to set Partner Status = Denied
Technology partners use the same form, but are not able to agree to the terms and conditions. Once they submit the form, they will be set to active. If the Alliances team wants to establish a contract with the partner, they must follow the Legal Request process in Salesforce.
If for any reason, a partner account needs to be created in Salesforce directly, requests for account creation can be made to #channel-ops within Slack.
DR - Partner Deal Type = Partner Sourced, Assist, or Fulfillment
If Google or AWS has brought us a lead/referred us a deal but will not be transacting on their Marketplace, then the following fields should be filled out on the Opportunity:
DR - Partner should be filled out using these SFDC accounts:
If Google or AWS has assisted on a deal and helped drive the customer to buy GitLab, but was not the original source of the opportunity, then the following fields should be filled out on the Opportunity:
Influence Partner = should be filled out using these SFDC accounts:
Required fields when requesting Google Cloud Credits on an Opportunity
Have you engaged with the GCP Team already? (Drop down: Yes, No)
Customer open to being a reference? (drop down: logo use, case-study, joint speaking session, etc.)
Credits being requested (Sales Rep enters in the amount of credits required to close the deal)
Once all required information is provided, it will be routed internally for approval.
Channel Neutral
Comp Neutrality applies to all GitLab Opportunities where a Partner is involved in the physical transaction (takes paper) and a Partner Program discount is applied on the executed Partner Order Form.
The maximum Comp Neutral payout is based on the applicable GitLab Partner Program discount matrix. If additional discount is needed in order to close the deal, that portion is not eligible for Comp Neutrality.
In the event a lesser discount is applied on the deal then what the Partner Program allocates, then the lesser discount will also be what is calculated for Comp Neutrality.
As a reminder, comp neutrality only applies to comp and does not retire quota. For additional information, please review Channel Neutral Compensation within the Sales Ops commission section of the Handbook.
For Partner Program discounts for PubSec, please reach out to #channel-ops on Slack.
Comp Neutral Calculation in SFDC
In the event the opportunity is going thru a Partner and therefore qualifies for CN, then the appropriate partner information must be filled out on the Opportunity and Quote in order for the CN field to calculate properly.
Required Partner Fields on the Opp:
DR - Partner
DR - Partner Deal Type
DR - Partner Engagement
Distributor (as applicable)
Required Partner Info on the Quote
Invoice owner contact and Invoice owner Type must be a Partner Account and Contact
Order Form must be a Partner Order Form
Example Calculation No. 1:
Partner Track : Select
Product : Standard (Previously Premium)
QTY : 25
Term : 1 year
Partner Deal Type : Resale
Partner Engagement : Partner Sourced
Deal Registration : Approved
Partner Program Discount : 15%
$228 x 25 x 1 = $5700 (price without program discount aka MSRP or List Price)
$228 x 25 x 1 x 15% = $4845 (quote/order form price with discount)
$5700 x 15% = $855 (comp neutral amount)
Example Calculation No. 2 (PubSec):
Partner Track : Open
Distributor : True
Product : Ultimate
QTY : 50
Term : 1 year
Partner Deal Type : Resale
Partner Engagement : Assist
Deal Registration : Approved
Partner Program Discount : 10%
$1188 x 50 x 1 = $59400 (price without program discount)
$1188 x 50 x 1 x 15% = $50490 (quote/order form price with discount)
$59400 x 15% = $8910 (comp neutral amount)
2-Tier Opportunities
If the Opportunity is going through a 2-Tier Channel (Distributor + Reseller), both Partner Accounts must be included on the Opportunity in the Partner Information section in order for both Program discounts to apply AND for Comp Neutral to calculate on both. Reseller should be in the DR - Partner field and the applicable Distributor in the Distributor field on the Opportunity.
Opportunities with GCP and AWS
For deals going through GCP and AWS, the Partner fields should still be filled out on the Opportunity but comp neutral will not calculate until the deal closes as partner discounts are done after the quote/order form is generated. Deal Desk will assist with this process.
Frequently Asked Questions
Where can I find the Standard Channel Discounts for my Partners?
How do I track the opportunity of a partner deal?
Please fill in at least one of the following Opportunity drop downs to identify the deal as a Channel opportunity.
If the partner registered the deal the Deal Registrarfield will need to be populated in the SFDC opportunity with the appropriate Partner Account.
If the Partner Assisted you (see above for definition) please populate the Partner - Assisted field in the SFDC opportunity with the appropriate partner account.
If GitLab sourced and sold the deal directly, and the partner is simply fulfilling the deal, please populate the Partner - Fulfillment field in the SFDC opportunity.
If an Opportunity already exists then SELECT the applicable one.
If not then select:
If creating new, the applicable details from the Deal Registration will map to the Opportunity and automatically tag it as a Partner Sourced opportunity. Any other system required fields will also need to be filled out. Be sure to update the opportunity owner into the correct sales rep's name, and out of the channel manager's name.
needs to be filled out before moving forward.
If approved, then a notification will be sent to the Partner, the Deal Registration system updated, and the Registration status updated to Approved.
