-
No more lookup filters in Managed Package context?
In my managed package (delivered to many customer orgs) I have active Lookup Filters on CustomObject__c.
I planned to add two more but ran into the “Max. 5 Lookup Filters per Object” limitation.
How can I cope with this? I would like to deactivate an old filter and add the new one but I fear that customer upgrades will fail as my package looks like it needs 6 Filters on Install. I had similar problems with External Id fields.
Do Lookup Filters behave the same way? Do I need to make a pre-release first, where I package the deactivated old filter, before I can package the new one
-
1 Reply
-
I checked around and can’t find confirmation of what happens to lookup filters in managed packages after passing the security review. But here’s what I do know: Once your managed package passes the security review and you have it listed as public, you will be granted your own resource space, with the only exception (that I know of) being tabs. This changes if you have an Aloha App and then even tabs are not counted against the org you install in.
For example, in a privately listed, managed package that hasn’t passed the security review yet, any triggers contained within will share the available resources with other triggers in the org (200 SOQL calls, 100 DML statements, 200K script statements, etc.) Once this managed package passes the review, the package gets its own set of 100 DML statements, 200 SOQL statements, 200K script statements, etc.
Although it’s difficult to find specific documentation regarding these limit changes after completing the security review, I’ve been through the review process numerous times and experienced these changes firsthand – along with having confirmation of these changes from premier support. Although again, I haven’t specifically checked for lookup filters in this regard.
So I would lean towards you getting your own set of lookup filter limits within your managed package – once certified. But I’m not 100% certain.
Log In to reply.
