Sometimes installing UnManaged Packages has given me problems while migrating Apex code even though the code is totally unrelated to the entity for which you have installed the package.
The workaround for this is to Inactivate the validation rules and then proceed with migrating your APEX code. If you have 18-20 validations like I do Inactivating these one by one can be a pain.
Solution
There's another workaround to this problem called Custom Settings.This data can then be used by formula fields, validation rules, flows, Apex, and the SOAP API.
Custom Settings allow you to create global objects and define global variables and have them access anywhere.
To create Custom Setting, click on Set Up---Develop---Custom Settings.
Click on New and give your setting a Name and Description. Mark the setting Type as Hierarchy and Visibility as Public.
Essentially you have created a global object which can be leveraged in validation rules etc and the object obviously needs some fields to hold values.
To create fields, in the Custom fields section, click New and select the DataType that you want to define.
To define values for this field at a global level, click on the Manage button--New and enter the desired value.
If you want to have different values by User or Profiles then click New and enter the desired value against the desired User or Profile.
Now, you are ready to use the global value say in your ValidationRule.
Create or Edit a Validation Rule on say the Case object and click Insert field, you should something like $Setup.V<ObjName>.<FieldName>.
Set up the rule as follows:
$Setup.ValProceed__c.ProceedFlg__c == TRUE && LEN (Description) < 10
The workaround for this is to Inactivate the validation rules and then proceed with migrating your APEX code. If you have 18-20 validations like I do Inactivating these one by one can be a pain.
Solution
There's another workaround to this problem called Custom Settings.This data can then be used by formula fields, validation rules, flows, Apex, and the SOAP API.
Custom Settings allow you to create global objects and define global variables and have them access anywhere.
To create Custom Setting, click on Set Up---Develop---Custom Settings.
Click on New and give your setting a Name and Description. Mark the setting Type as Hierarchy and Visibility as Public.
Essentially you have created a global object which can be leveraged in validation rules etc and the object obviously needs some fields to hold values.
To create fields, in the Custom fields section, click New and select the DataType that you want to define.
To define values for this field at a global level, click on the Manage button--New and enter the desired value.
If you want to have different values by User or Profiles then click New and enter the desired value against the desired User or Profile.
Now, you are ready to use the global value say in your ValidationRule.
Create or Edit a Validation Rule on say the Case object and click Insert field, you should something like $Setup.V<ObjName>.<FieldName>.
Set up the rule as follows:
$Setup.ValProceed__c.ProceedFlg__c == TRUE && LEN (Description) < 10
which means that if the global variable == TRUE and < than
10 chars is entered in the Case Description then have an error displayed to the
user.
As you migrate
your validation rule to different environments, set the global variable to
false and try to migrate your APEX code, this will prevent the Validations Rule
from firing. Once the migration is done simply set the global variable to TRUE.
That way, with
18-20 validation rules per object you do not have to worry activating and
inactivating them one by one.
No comments:
Post a Comment