• Vinny Gebhart 10
  • NEWBIE
  • 0 Points
  • Member since 2016

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 5
    Questions
  • 2
    Replies
Using Metadata API to update org and running into this error in certain scenarios.  II have other list views that also exist previously but those load fine.  I found an article about sharing settings however I've tried removing sharing settings, changing to public group but these continue to fail.

objects/Contact.object (Contact.InActive_Contacts) -- Error: This View Unique Name already exists or has been previously used.  Please choose a  different name.

Is there a way to bypass this check?

-Vinny

 
Hi all,

Here's our back story:

We have an app that we developed (with a partner) to be a managed package deployment.  It's not meant for app exchange, simply a package we deploy for each of our clients when they come online with our service.  The partner who developed the org worked from one sandbox for their development, then bundled components as they were complete and moved to a "packaging" dev org where they created a managed package which we then install on client orgs.

Here's our current challenge:

That original org where the app was developed is no longer sufficient as we're expanding our dev team.  Our goal is to pull all of that code to a new fully licensed org so we can spin off developer sandboxes, refresh them as necessary, and streamline our deployment and development processes.  The issue is when we use the meta-data API to extract all code from the original org, we're unable to deploy it to a new org due to many dependencies and circular references between classes, objects, etc.  It seems Salesforce isn't able to handle "fixing" these dependencies on the fly.  We have tried scrubbing the XML package for any dependendent fields, classes, etc. which does limit the number of errors we get but we do still need to deploy all of the code at some point and at this point its incredibly manual and best described as "brute force".

Can anyone recommend a better / stronger practice for deploying a batch of metadata, code, classes, etc. to a new org in a way that will be successful?  Please note - the reason we're not deploying this as a managed pkg is so developers can work on the code / classes directly and test in place.  

Any help is greatly appreciated.

-Vinny