Organisation dependent App for AppExchange

Question

I was wondering whether there is any way to build an application to be deployed in AppExchange which may have some customizable class or maybe use some code on the customer side.

My situation is as follows: I'm preparing an application which connects to my own WebService and I'm defining a Constants class to set the login credentials for that WS, which would be different for every new organisation using my App. Thus, for every installation I would need to change these values for the organisation ones.

In the other hand, I'm also dependant on the objects that the organisation would want to send to my WS: sometimes that organisation may want to send custom objects which would need some previous concrete processing. Actually I'm isolating all organisation dependant code into one class called SpecificDataProcessor but I feel that that's not the right approach because I won't be able to edit that SpecificDataProcessor for each organisation that is installing my App.

Of course, the customer would need to add custom Triggers to fire my code, but I think this is not a problem at all. Or is it?

Can you provide me the best solution for all of this situation? Is it even possible to build AppExchange apps which are organisation-model dependant?

Thank you very much. Martín.

Answer 1

When you want to vary simple data elements you can make use of hierarchical custom settings. If you make these public then they can be directly edited in the customers org. But for data such as a password, a Salesforce security review would recommend that you create Visualforce page for the editing so the password can be masked using apex:inputSecret.

But if you want to allow logic to be customised, then a general approach is to provide a global interface in your managed package that customers can implement using their own Apex code. Your managed package can then accept a class name - via a custom setting say - and use Type.forName to create an instance of that class and then invoke the methods defined in the interface. This approach is illustrated in the Type Class documentation.

On the point of data model dependency, you can create managed packages that are not tied to specific data models by making use of dynamic SOQL, accessing fields through SObject's get/put methods, and discovering the data model through describe methods. But the coding gets harder.