3

We have a number of validation rules that improve data quality as it is entered. However we have a number of records that are non-compliant with these validation rules.

We've just added some workflows and they keep failing because of the validation rules. This is irritating because its more important that they work than the validation rule.

So it seems that

  1. I can turn the validation rules off which impacts data quality
  2. I can abandon the workflows which stops us delivering a new process
  3. Can I do something else?

Looking at the error it seems that the issue is the allornone requirement that Process Builder puts in. In this case, if I understand AllorNone correctly a graceful degradation would be acceptable for us have a SOME. Is this possible using Process Builder?

Note - its cross object updating so I can't use a normal workflow and I'm trying to avoid a trigger if I can....

Encountered unhandled fault when running process Structural_Segment_Update/XXXXXXXXXXXXXXXX exception by user/organization: XXXXXXXXXXXXXXXX/{4}

UPSERT --- UPSERT FAILED --- ERRORS : (ALL_OR_NONE_OPERATION_ROLLED_BACK) Record rolled back because not all records were valid and the request was using AllOrNone header --- for SFDC record with ID : 0019000001JUUlfAAH,

caused by element : FlowRecordUpdate.myRule_1_A1

caused by: UPSERT --- UPSERT FAILED --- ERRORS : (ALL_OR_NONE_OPERATION_ROLLED_BACK) Record rolled back because not all records were valid and the request was using AllOrNone header --- for SFDC record with ID : XXXXXXXXXXXXXXXX,

Salesforce Error ID: 399992965-72394 (-705207071)

2
  • 2
    Maybe change your validation rules and add exclusions for records that have been created prior the date the VR has been created. For an instance if you create a VR today and the workflows must still work on old records even they're not compliant, in your validation rule add && CreatedDate >= 07/05/2015 etc. One possible workaround May 7, 2015 at 5:17
  • 1
    What a wonderful idea :) A thousand salaams and blessings on your family for a hundred generations. May be OTT but it captures how I feel right now :) May 7, 2015 at 9:13

3 Answers 3

3

As I previously commented on the question (posting it as an answer this time), one of your quick and dirty options will be to change your validation rules and add exclusions for records that have been created prior the date the VR has been created. For an instance if you create a VR today and the workflows must still work on old records even they're not compliant, in your validation rule add && CreatedDate >= 07/05/2015 etc.

I would consider cleaning up the data in the org asap as it might lead later to even bigger issues. Let alone if you need to do data migration and such.

2

Seems like your logic is incorrect.
you should go over your Validation Rules Crietria's and change them to meet your requirements, you can use creative criteria elements such as recordType/ Profile Id to decide for whom the VR will run.
But Validation Rules will always work before WF and will run before Trigger as well so if your logic is incorrect Trigger won't help you check out order of execution -
https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_triggers_order_of_execution.htm

If logic is correct - I guess you can work around your Trigger to stop Validation Rule run Trigger and than turn on the Validation Rule again when job is done. (Use custom setting for that - will be wiser).

0

A good practice for both validation rules and workflow is to include criteria that limits when they are fired to when changes occur that are relevant to the work being done by the validation rule or workflow.

For example, if you have validation rule to make sure that Account.Name is always at least three characters long, include in the criteria a check that it's a new Account or that the Account Name is being changed:

AND(
  LEN(Name) < 3,
  OR(
    ISNEW(),
    ISCHANGED(Name)
  )
)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .