Validation rules

Follow
Table of Contents

1. Referral validation rules
2. Partner Referral validation rules
3. Partner validation rules
4. MicrosoftSolution__c validation rules
5. ReferralMicrosoftSolution__c validation rules


You can disable any of the packaged validation rules, e.g. if you want to upload historical data. But do so at your own risk and in the off-hours because most of these validation rules are designed to prevent invalid data that will break the sync between Salesforce and WorkSpan (and other systems).

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.

0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.