Partial success on load to people due to "Duplicate Record"

  • 2 September 2022
  • 11 replies
  • 197 views

Userlevel 1

Customers feel that the process of rule with action type load to people with company association undergoing "partial failures" just because there's a duplicate entry in the Person action (even though that's expected in the cases where they are having the same person associated for two different Companies) is a bit irrelevant.

They feel that it would be great if we would create an independent action type that would allow the users to directly update a Company Person records based on GSID (identifiers) without having the dependency on the additional Person component within the same action.


11 replies

Userlevel 2
Badge +3

This is a product defect, not an enhancement request.

The whole point of having a Company Person object and not just a Person object is so that a Person can have different attributes across multiple Companies.

The only way data can be loaded to Company Person where a Person has different attributes at different Companies is when there are 2+ rows of data for each Person being loaded, which will always result in a failure with Partial Success status.

Please fix this bug.

Userlevel 7
Badge +2

100% concur.  @anirbandutta do you know who the PM is for Company Person?

Userlevel 7
Badge +2

@Dheepak G could you check this?

Userlevel 3
Badge

@Sai Tangirala Hi, I’ve clarified in our internal chat also that we’re working on how best to refine the status given the confusion it’s been causing, so it’s been looked into. Also, it’s been treated as a defect therefore it cannot be categorised as a new idea.

 

Userlevel 7
Badge +2

Thanks for the pointers everyone; this is now converted to a Discussion.

@Sai Tangirala let’s keep this thread updated with the progress we make. Cheers!

Badge +1

I remember this surfaced a few months ago (introducing the Partial Success due to Dups) and then was reverted back - it looks like it came back around Sept 6-7? 

Reason I’m adding input is that I’ve seen a huge performance degradation in RuleChains since the Partial Success status started back up. We have a series of Chains that typically wrap up between 3-5am but have now run to 10am+ these last two days (since the Partial Success notation started).

Has anyone else noticed such as dramatic shift in Rule execution?

This defect is also causing us issues. The noise from all the partial successes are cluttering our alerting channels making it harder to spot real issues. The rules should be able to handle expected behaviour  (many:many company-person relationships) without raising errors.

The rules using the load to people action also seem to be taking much longer than they previously took when they are raising these partial success errors, to the extent I have it occasionally timing out and aborting, which subsequently aborts the rest of the rule chain the load to people rule is in.

Badge +1

We’ve been struggling with this for nearly a month now - failed Rule and RuleChain execution, which cascades in to subsequent chains, executions, Data Designer refreshes and results in bad data to the End User.

@will.hall as you’ve indicated, I too feel like Load to People is the culprit - something is leaking there and blowing out everything else.  I just ran a Manual Rule Test (not even loading to the objects - just running the Rule) and see clearly that COMPANY PERSON is struggling - every other process generally takes a few seconds but those trying to Load to Company Person are taking 30-50 MINUTES - and this isn’t even actually loading to the Object!

 

Userlevel 2
Badge +3

I’ve recently seen the same performance issues. Every time I raise a ticket, by the time support get around to escalating/reviewing it, the queued/skipped rules are back to relatively normal and it’s always apparently an ‘isolated incident’.

Here are my logs from earlier — a very basic rule in development which copies the value in one field to another. This rule is filtered down to a single Company and a Single person for testing purposes and still took 1.5 hours

We can’t test/debug rules when even the simplest ones take that long to execute and this is impacting all other rules across the instance, and therefore the integrity of the data that rely on them.

To make it worse, the Rules Activity page doesn’t reflect reality as I know there have been rules running between 9 am and 5 pm today, which leaves us even more in the dark about what’s going on

 

 

Badge +1

@jparker thanks for submitting your observations as well - something I noticed, too, because we threw the log in to an Excel spreadsheet: I fear the Rule Action sequences aren’t firing properly/in the right order.

My COM is following up with Engineering on this, but it might be good for you to review some of your more complicated Rules as well.  In my case, I have a Rule (untouched, so same Rule running previously and now) that has 5 separate Actions that need to fire in sequence.  When comparing the two logs (most recent Partial Success vs. last full Success) I saw that the new runs appear to either be firing out of sequence or overloading their queues and flooding each other, eventually Failing (in the Rule run) but still indicating that it was a Partial Success?

 

Userlevel 7
Badge +2

@Shilpa Gumnur since this is (rightly) being classified as a defect, any chance we can have more frequent updates on the status here? Thanks!

Reply