1. Referral validation rules
2. Partner Referral validation rules
3. Partner validation rules
4. MicrosoftSolution__c validation rules
5. ReferralMicrosoftSolution__c validation rules
All the fields, validation rules and help texts are outlined in the SF Field Dictionary.
1. Referral validation rules
The following validation rules ensure that the fields that AWS requires (see Amazon (AWS) flows) are populated on an Outgoing Referral:
- AWSCompetitiveTrackingOtherRequired
- AWSContractVehicleRequired
- AWSPartnerPrimaryNeedOtherRequired
- ClosedLostReasonRequired
- AWSCustomerSoftwareValueCurrencyValidation
- AWSCustomerSoftwareValueValidation
The following validation rules ensure that the fields that MPC requires (see Microsoft Partner Center (MPC) flows) are populated on an Outgoing Referral:
- MicrosoftCustomerDunsOrAddressRequired
- MicrosoftCustomerContactRequired
There are no specific validation rules for Google use cases yet.
The following validation rules ensure that the currency code (see here) is a string of 3 letters. It does NOT ensure that they form a valid ISO currency code, so it can be 3-letter nonsense like XYZ.
- DealSizeCurrencyValidation
- ForecastValueCurrencyValidation.
The following validation rule ensures that the Referral Type is not changed (from Outgoing to Incoming or vice versa) after Referral creation because different types imply different flows, which are in part enforced by different record types which should not be changed on the fly:
- ReferralTypeCannotBeChanged.
2. Partner Referral validation rules
The following validation rules ensure that the currency code (see here) is a string of 3 letters. It does NOT ensure that they form a valid ISO currency code, so it can be 3-letter nonsense like XYZ.
- DealSizeCurrencyValidation
- ForecastValueCurrencyValidation.
The following validation rule ensures that the Partner is not changed after Partner Referral (and Referral, by extension) is created because the change will not be propagated to WorkSpan, and it will create data discrepancy:
- PartnerCannotBeChanged.
If you absolutely have to change the Partner on an existing Partner Referral (and Referral, by extension), follow the 4-step process described here.
3. Partner validation rules
The following validation rule ensures that the Partner ID is not changed after Partner is created because the change will not be propagated to WorkSpan, and it will create data discrepancy:
- PartnerIdCannotBeChanged.
If you absolutely have to change the Partner ID on an existing Partner record, follow the 4-step process described here.
4. MicrosoftSolution__c validation rules
The following validation rule ensures that the Solution ID is not changed after MicrosoftSolution__c is created because the change will not be propagated to WorkSpan, and it will create data discrepancy:
- SolutionIdCannotBeChanged.
If you absolutely have to change the Solution ID on an existing MicrosoftSolution__c, follow the 4-step process described here.
5. ReferralMicrosoftSolution__c validation rules
The following validation rule ensures that the Solution is not changed after ReferralMicrosoftSolution__c is created because the change will not be propagated to WorkSpan and it will create data discrepancy:
- SolutionCannotBeChanged.
If you absolutely have to change the Solution on an existing ReferralMicrosoftSolution__c, follow the 4-step process described here.
Comments
Article is closed for comments.