2

I want to build a managed packaged and ultimately deploy it on the AppExchange. My app is targeted for the B2C model (Business to Consumer).

Since in salesforce public contacts are required to be tied to an account, I'm wanting to put a trigger on both the standard Account/Contact objects so that way when a new contact is created I also create a corresponding account and vice-versa (similar to the way the Non-Profit Starter Package) works. I'm concerned about doing this though as these are standard objects and it seems it could cause some conflicting behavior for customers if I've added a trigger like this on the key standard objects like Accounts and Contacts.

When developing a managed package should I consider creating all custom objects? I hate to recreate the standard account/contacts, but it seems like it may be my only option if I want to have full flexibility to do what I want and also not affect the way a customer is currently using salesforce Accounts and Contacts.

Does anyone have any thoughts on the impact of building functionality on top of standard objects when creating an appexchange app? It seems like tinkering with the standard objects might be a bad idea?

Improve this question
2
  • No, I suppose I don't want them to fire on all accounts and/or contacts. So you're suggesting maybe define a record type so that way I wouldn't conflict with the way a potential customer is using Accounts/Contacts?
    – West
    Aug 11, 2014 at 1:07
  • Yes. I just moved the idea to an answer rather than a comment.
    – Daniel Ballinger
    Aug 11, 2014 at 1:08

1 Answer 1

Reset to default
1

Create your own Record Type for Accounts and Contacts that will indicate the records are applicable to your managed package.

Then check if the Account/Contact has the required Record Type before applying the trigger.

I.e. The triggers only make changes if the Account/Contact is of a configured RecordType

This will also help isolate your customizations from any other installed packages that are also working with Account/Contact.

Note: Avoid hardcoding any RecordTypeIds in the trigger. It is better to look them up as required or make them configurable.

If you want your triggers to work for multiple record types you could examine a particular field to see if it indicates the record is applicable. This could be as simple as having a Checkbox on the Account or Contact that indicates your code should be applied to the record.

With triggers I also make it a habit to provide a bypass custom setting. Create a hierarchy checkbox custom setting that indicates if the trigger should be bypassed. Then an admin can configure the custom setting to skip the trigger for certain profiles/users as required. This can be extremely useful when loading data into the system.

Improve this answer
1
  • The described solution should always come with a custom setting for finetuning by the admin (e.g. bypass trigger for user/group/profile/record types). It is never a good idea, that the customer needs to swich to your packaged record type in oder to use your solution. For almost every customer it is a very high hurdle to change hs data in order to work with your solution.
    – Alexander Johannes
    Aug 11, 2014 at 11:22

You must log in to answer this question.

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