• Mike Rocha
  • 0 Points
  • Member since 2014

  • Chatter
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 5
  • 0
We have a self-signed certificate that is expiring in a few days. We did not create this certificate and do not know how we will be impacted when this certificate expires. We believe it is related to Environment Hub since the Environment Hub and the certificate are created at the same time. Does any one have any leads as to what this certificate is about and how it expiring will impact us?

We are an ISV partner and our application currently leverages the SF OAuth refresh token flow to get access to our users' Salesforce instances via the REST API. Upon receipt of an access token for communicating with the REST API, we record the instance_url parameter returned as part of the response and use that URL to communicate with the REST API, as outlined at 

It seems there has been the occasional user that gets a different instance_url value than their org is assigned. For example, the instance_url parameter returned is na1.salesforce.com, but their actual instance (the instance they're redirected to when they login to SF) is na12.salesforce.com. As a result, the API calls fail.
I'm trying to set up a web service callout upon creation of a new sfLma__License__c object. I've set up an after insert trigger on the object, and have a call to an @future method for the web service callout in a separate class. 

For whatever reason, the trigger never seems to actually execute. It executes well if I manually create the license record, but licenses that get created by the LMA from AppExchange app installs do not execute the trigger.

I don't quite know how to debug this issue either, as the LMA user isn't a user that we can view debug logs for.

Anyone have any ideas?

We have a managed released package currently undergoing security review. While that is happening, we would like to make some changes to the tab layout of our application. Unfortunately, it seems that I can change very little to do with our tabs in our managed released package. I would like to get the package into the hands of beta testers, but I need to make the aforementioned tab changes first. Is there any way at all that I can do this? I would rather not have the beta testers install an unmanaged package, as there are post-installation steps that they would have to execute manually.

I've poked around the forums and seen mention of this issue, but I have yet to come across a solution.
My application uses an authorization key stored in a protected custom setting to authenticate users to connect to an external web service. Since you can't define a default value on package install for a protected custom setting, I've created a post-installation class that manually sets the custom setting value via code.

The problem is, our security review results suggest that the key should not be stored in code in plain text. How can I go about setting the protected custom setting value if not from code? I'd rather not have the user do this manually.

Anyone have any suggestions?