8

Background: I have an org that uses person accounts and an appexchange package that does not support them. However when looking into why they're unsupported the only thing that does not work is that triggers designed for contacts are not firing on person accounts (expected, they fire account triggers instead).

However as the contact trigger is managed I can't just copy it over and apply it to accounts to get this working. I am free to write any apex needed in my own org, so I could for example write a brand new apex trigger on account that manually performed DML on the contact sObject. However I tried this and saw account triggers only running despite the explicit update op on a contact.

With all that said, is there any way to get salesforce to run contact triggers on my person account?

Improve this question

5 Answers 5

Reset to default
7

If there's a way to do it, I haven't found it.

However, though it doesn't help your immediate need, it's not hard for managed package vendors to add account triggers, identify the person accounts, query for the backing contacts and run the same code they would run if it were a contact trigger - that is, assuming they've designed their software correctly.

So, it may be time to contact the package vendor and see if they can help you out.

Improve this answer
3
  • 1
    +1 for asking the vendor to helpl support Person Accounts, which are native SF.
    – Mike Chale
    Commented Sep 7, 2012 at 1:04
  • It sounds like this is going to be what happens, although it's 6+ months out. No fun, but workable. It's really non-sensical how an explicit DML operation on the contact part of the person account doesn't invoke contact triggers though.
    – ca_peterson
    Commented Sep 7, 2012 at 1:56
  • Well, it's non-sensical to us, but I suspect there are some good reasons for it on the platform side. For one thing, they'd have to add a bunch of internal code to try to puzzle out whether the contact update was coming from our DML operation, or from one generated internally. And that's not necessarily obvious - if you update one of the mapped files (__pc), on the account, that updates the contact. So whose DML is it? Which trigger should apply? The existing choice is, I'm sure, easier for them to implment and more efficient.
    – kibitzer
    Commented Sep 7, 2012 at 19:56
3

OK, I want to preface this with the statement that this is probably a horrible solution. A truly dark, abominable solution. Working with Salesforce I've had to become somewhat accustomed to creating monstrous code. Do not read further if you are faint of heart or short of courage.

You could create an evil twin contact record. It would have all the same data as the Person account but it's a contact. You write a trigger on the account so when a person account is updated, it also updates it's evil twin the contact record. This will fire the contact trigger.

Now, I don't know what that contact trigger is doing that you need - is it modifying the contact record? If so then we have more gruesome work ahead of us. Now, we need to take the modifications to the contact and use another trigger to update the person account. We'll have to be careful to not cause a recursive loop of unholy updates between person account and contact.

If the trigger was affecting other records (non contact) we are possibly fine.

I'm sorry if this answer has made you sick to your stomach - imagine how I must feel having written it. A swirling maelstrom of denormalized shadow data... It's an interesting approach - certainly not a good approach... but it just might actually work.

Improve this answer
1
  • I like how evil this is but I'm afraid it might not work. The vendor trigger is rolling up data from child objects with somewhat complex logic that I'm loathe to try and duplicate as the child objects are on my person account. Upvote for creativity and an otherwise very solid answer for others!
    – ca_peterson
    Commented Sep 7, 2012 at 1:55
3

I do not think you can invoke managed package's Contact triggers on Person Accounts. This really should be a re-work on the managed package to make it "Person Account compatible". If you have the control on the managed package, you could refactor the code to allow the same logic of Contact triggers to be invoked on Person Accounts. See my blog post: http://force746.wordpress.com/2014/02/19/invoke-contact-triggers-logic-on-person-accounts/

Improve this answer
2

Set up your trigger on the account object. When it fires in the instance of a Person Account all fields typically on the contact will be available on the account object, e.g. a.Lastname, (custom fields will end with __pc).

Improve this answer
1
  • The problem is that I can't replicate the vendor's logic in my own custom trigger as the vendor's trigger is managed and I don't have access to the source behind it. However the part about __pc is quite interesting, thanks for that.
    – ca_peterson
    Commented Sep 6, 2012 at 18:23
1

I don't use Person Accounts however if Workflows still fire appropriately when Contacts are updated then you could use an e-mail action to a Salesforce e-mail endpoint to fire an e-mail service.

http://wiki.developerforce.com/page/An_Introduction_To_Email_Services_on_Force.com

Here is a blog article that goes into the specifics of a process that fires a workflow, generates an e-mail to an endpoint which then runs a particular class.

http://iwritecrappycode.wordpress.com/2011/01/31/invoke-apex-class-via-workflow-rule/

Improve this answer
1
  • The problem with this is that once I've invoked the email service how can I run contact triggers on the person account? Any DML operations on them appear to always run account triggers instead which puts me back in the same situation I started from.
    – ca_peterson
    Commented Sep 6, 2012 at 17:23

You must log in to answer this question.

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