Skip to main content

Deleting Components in Managed Packages

Starting Spring ‘14, ISVs can delete the following types of components when updating a previously released managed package.
  • Custom Buttons or Links
  • Custom Fields
  • Custom Objects
  • Custom Tabs
  • Field Sets
  • Record Types
  • Validation Rules

The deletion of these components was not supported previously, to avoid the risk of data loss or integration failures in subscriber
organizations. However, the number of such components in a complex package can grow very large over multiple release cycles.
The ability to delete managed components can be very useful in such cases. It gives ISVs greater flexibility in maintaining and
upgrading their apps.

Deleting any component will permanently delete any data that exists in that component, delete tracked history data, and
change any integrations that rely on the component, such as assignment or escalation rules. Also, once you delete a component
in a managed package, you can’t restore it or create another component with the same name.

No data or metadata is ever deleted in a subscriber organization without specific action by the customer. Subscribers who
upgrade to the new package version will still have the deleted components available in their organization. They’re displayed
in the Unused Components section of the Package Details page. This ensures subscribers have the opportunity to export data
and modify custom integrations involving those components, before explicitly deleting them. For example, before deleting
custom objects or fields, customers can preserve a record of their data by going to Setup and clicking Data Management >
Data Export.

The following restrictions apply when deleting managed components.
  • A component of any type is not deletable if it’s referenced by any other metadata, such as workflow rules, validation rules, or Apex classes.
  • A custom object is not deletable if it includes any of the following: Apex Sharing Reason, Apex Sharing Recalculation, Related Lookup Filter, Compact Layout, or Action.
  • Deleting a custom field that is referenced by a custom report type in the same package is not recommended, as that will lead to an error when installing the upgraded package.

Comments

Post a Comment

Popular posts from this blog

Mashup Integration in Salesforce

During preparation for TA certification exam, I came across a word Mashup for integration a number of times. I explored about it and below is description:- Mashups, sometimes called “composites,” are hybrid applications created by bringing together several data sources and Web services to create a new application or to add value to an existing application. Behind the scenes, mashups may require different levels of integration, depending on whether the mashed-up data is only meant to be viewed, whether it can be edited, and whether data is actually transferred between systems. There are three types of mashup:- Client Presentation Mashup - In this type of mashup the integration takes place strictly at the visual level. It makes possible to view data from two or more applications in a browser,  without actually moving data between the applications. Example - Google Maps. Client Service Mashup - As mashups evolve, they are becoming more complex and sophisticated. Client...
15 comments
Read more

ReadOnly Annotation

Use Case:- You want to show up to 10000 record on single VF page. Count of records based upon some business requirement where number of records could go up to 1 million. So far, it was not possible to achieve above in VF page because of following limitations:- The maximum number of items in a collection that can be iterated over using components such as <apex:dataTable> , <apex:dataList> , and <apex:repeat> is 1000. Normally, queries for a single Visualforce page request may not retrieve more than 50,000 rows. Solution:- But with API version 23.0 , salesforce has introduced ' ReadOnly ' annotation which has following functionality/restriction:- The @ReadOnly annotation allows you to perform unrestricted queries against the Force.comdatabase. All other limits still apply. It's important to note that this annotation, while removing the limit of the number of returned rows for a request, blocks you from performing the following operations ...
Post a Comment
Read more

Grant Access Using Hierarchies

Problem There is a custom object say 'XYZ' and OWD for this is set to ' Private ', which means record of this can be seen by only owner and users above in role-hierarchy and territory. However, to share this with other user, we can manually share it. The problem is that I don't want other users, who are above in role-hierarchy and territory of the user with whom record has shared, can see it. Solution We can un-check ' Grant Access Using Hierarchies ' check box for object 'XYZ' on 'Sharing Settings' page. We can go to Setup >> Security Controls >> Sharing Settings and click on ' Edit ' button. On the edit page, we can un-check ' Grant Access Using Hierarchies ' for required object.  Major uses of 'Grant Access Using Hierarchies' are:- If you disable the Grant Access Using Hierarchies option, sharing with a role or territory and subordinates only shares with the users directly asso...
1 comment
Read more