Hi,

  Our company will serve as an ISV.  

  We'll provide managed packages for our partners.

  However, the development of such packages should go through dev->qa->stage->prod processes.  The Dev team/QA team/Distribution Team are independent from each other.

 What's the best practice of the development lifecycle in this case?  Or, which books should I read?  

 In relation to an Outbound Message, if salesforce  does not receive an Acknowledgement back from the designated endpoint after _?__ seconds, the message is added to the retry queue.

We are an OEM partner and last year created an app and went through the security review and were approved.

In our scenario we fully administer the apps and act as the administrator on behalf of our clients.

In addition each client has customizations that could be different between each program.  Are we required to have a managed package if we are fully supporting and administrating each org or can we just have an unmanaged package and handle each org and customizations separately within each org.  Its very complicated with managed apps to have a design locked down when each client can we a little different.

I do understand the implications that we can't "push" updates to orgs by not using a managed package. 

So my questions is as an OEM Partner is it okay to just have an umanaged package?  And just make any customization / tweaks for each client in their particular org.  

Anyone here have a Managed Package with Flows enabled able to upgrade app (either patch or full upgrade)? We are getting errors that says "cannot upgrade part of a Managed Package" and get references to all of the Flows in our Package. Tried making Flows in subscriber org inactive, still didn't work.

Hi All,

I have two managed packages available on the appexchange which are doing quite well.

But after a while and learning more from the force.com platform i have better ideas of designing and developing my applications.

I cannot change these things in the current package as i cannot delete objects and functions from already released packages. Is there a way to start fresh with a version 2.0 of my package and attach this package to the same appexchange listing?

Thanks,

Sten

Hi folks,

We've got an unmanaged package we're trying to deploy, and running into an issue when we are installing the package.  We have the following Record Types across a few objects:

Name / DeveloperName / SobjectType

Donation / Donation_Lead / Lead
Donation / Donation_Campaign / Campaign

Donation / Donation_CampaignMember / CampaignMember

Already existing in the SFDC instance is the following...

Donation / Donation / Opportunity

For reasons we can't understand, the package install fails with the following error:  "Duplicate Name    Record Type    The name "donation" is already used on component type: Record Type. Please rename existing component."

We can't figure out why this would be happening.  From the UI, we have no problem in creating Record Types with these Names(Label) and DeveloperNames (Name).  Any idea why this would error out in packaging install only?

-Ryan

Hi!

Could someone please advise on how FLS on standard objets custom fields is applied when installing a managed package? I am a bit disappointed by the difference between what I'm seeing in documentation and what I'm getting as the result.

We have external id text fields for accounts and contacts which we then use for integration with our systems, let's say: Account.Custom_ID__c and Contact.Custom_ID__c. We are installing this package to both new SF environments and SF environments that may already have the same custom fields for contacts and accounts. Though 'installed' custom fields have namespace prefix and thus their names are different from the ones that had previously existed in these SF orgs, it seems that their visibility depends on it. I have tried different  combinations of SF orgs and step 2 security levels  for installation and here are my conclusions:

1. Grant access to admins only. Expected: all custom fields from the package are visible for System Administrator profile. In reality: custom fields are not visible to any profile (if these fileds already exist in this SF org) OR some chaotic set of profiles (not only administrator and not only custom profiles) has visibility checked for this field (otherwise).
   
2. Grant access to all users. Expected: all custom fields from the package are visible for all custom profiles. In reality: the same as for previous option.
3. Select security settings. Here I should be able - in theory - copy some of profile settings from the custom profiles that I included into package. In reality: if these fileds already exist in this SF org then they (the new ones) are not visible to any profile, otherwise they are visible to all profiles. Regardless of the mapping I've chosen.

Sources of information that I used:

Installing a Package 

Salesforce Packaging Guide

Please let me know which part of it I am getting wrong.

Thanks in advance.

Hi,

  Our company will serve as an ISV.  

  We'll provide managed packages for our partners.

  However, the development of such packages should go through dev->qa->stage->prod processes.  The Dev team/QA team/Distribution Team are independent from each other.

 What's the best practice of the development lifecycle in this case?  Or, which books should I read?  

 In relation to an Outbound Message, if salesforce  does not receive an Acknowledgement back from the designated endpoint after _?__ seconds, the message is added to the retry queue.