I'd like to be able to see from the Accounts level stage if an Account is a parent of something else, without clicking "View Account" hierarchy.

Now I was going to automate this by using this "true/false" field and then using the Highligher Salesforce app to highlight the field in a certain colour if it was a parent account, or it was a child account

This way I can look at the Account and depending on the colour, automatically know if it was a parent or a child account.

I swear there is an ability to create an IF function for this, but I don't know how to set the parameters to check to see if an account has a hierarchy

I am running into a very strange issue with my unit tests.  When I run each test or test class individually they all pass fine.  The problem occurs when I try to run multiple tests at once or a test suite I put together.  I've been using case assignment rules to put new cases into queues and they work fine.  The problem I've found from going through the debug logs is that when more than one test is run at once, the case assignment rules never get called.  Going through the logs I don't even see them mentioned though other custom workflows do get triggered.

Does salesforce skip case assignment rules when running large tests?  If so will this cause a failure for deployment to production and if it will is there a way to make the case assignment rules fire?

Hello All,

 

I am facing hard time in adding a button in Console Tab(By that I mean to add a button in Console page, Not service Console). Button's functionality is just to launch a visualforce page.

 

When a button is added in Service console, it provide an awesome behaviour, just like Facebook or Salesforce chat. And on click of custom console button, page open as nice small popup.

 

But now I want the button to be added in Console Page(Even if it could launch a page instead of service console behaviour, It would work for me).

 

Please let me know if any of you have encountered similar situation.

Thanks for your time!!

This post talks about OAuth, but the exact same issues apply for username + password
interactions.

Salesforce has multiple instances on the backend, but uses a single "front door" for

logins (login.salesforce.com).  After successful login, you are sent to the right instance
to connect to (na15.salesforce.com, cs1.salesforce.com, etc).  At the user level
this is handled with a simple redirect; at the API level this is information passed
back in the login response.

HOWEVER, that top level unified domain only works for production logins.  Sandbox
logins have to use a different domain (test.salesforce.com), even though there
are *many* situations in which the calling code cannot possibly know which domain
to use.


As an example, let's say you want OAuth support in your API client app.

The first step in the OAuth flow is sending the user to a special page at which
they can OK access by your app.  You need to be able to determine if the user
is sandbox or not, because if they are, the initial "approve access" URL is
different:

 

normal: https://login.salesforce.com/services/oauth2/authorize
sandbox: https://test.salesforce.com/services/oauth2/authorize

This is annoying but surmountable - given that you are already interacting with the user,
you can probably figure out some hamfisted way of determing which URL to send them to.

But the next step is totally opaque.

The user authorizes access, and is redirect to your redirect_uri.  Your redirect_uri
is given a single parameter ("code") for the next call to "authorization_code".

In other words, your redirect_uri page is given zero indication of whether the given
code is used in the sandbox or not.

The only solution is to try to the "authorization_code" on the production URL, and if
that fails, cache the error & try the sandbox URL.  If that works, great, you know
it's a sandbox situation.  If try #2 fails, you now have two errors, and you need
to arbitrate amongst them to decide which to bubble up to the user.

 

(Note there is a totally nasty hack to guess sandbox vs. production - you could
look at the HTTP "Referrer" header, and hope that it's present & correct, and
then perform some mapping by which you hardcode that "cs4.salesforce.com" is
sandbox but "na3.salesforce.com" is production...  I do not count this is a
robust solution)

Given that the entire point of "login.salesforce.com" is to provide a single
"front door" that then tells you which actual domain to use, why don't sandbox
logins use the exact same front door?  Using "test.salesforce.com" for logins
means that client apps that wish to support the sandbox are needlessly complex.

Edit: it is possible to pass a "state" parameter to the oauth login page, and that will get passed back

to the redirect_uri, so one can detect sandbox prior to sending the user to the login page, and then

encode that knowledge into the "state" parameter so the redirect_uri knows.  It's a solution for this

particular case, but in general having to decide ahead of time on the "front door' endpoint means

that everyone who does an integration has to cart around extra data about each oauth token

(ie, whether it is sandbox or not). Still seems like a design bug.

This post talks about OAuth, but the exact same issues apply for username + password
interactions.

Salesforce has multiple instances on the backend, but uses a single "front door" for

logins (login.salesforce.com).  After successful login, you are sent to the right instance
to connect to (na15.salesforce.com, cs1.salesforce.com, etc).  At the user level
this is handled with a simple redirect; at the API level this is information passed
back in the login response.

HOWEVER, that top level unified domain only works for production logins.  Sandbox
logins have to use a different domain (test.salesforce.com), even though there
are *many* situations in which the calling code cannot possibly know which domain
to use.


As an example, let's say you want OAuth support in your API client app.

The first step in the OAuth flow is sending the user to a special page at which
they can OK access by your app.  You need to be able to determine if the user
is sandbox or not, because if they are, the initial "approve access" URL is
different:

 

normal: https://login.salesforce.com/services/oauth2/authorize
sandbox: https://test.salesforce.com/services/oauth2/authorize

This is annoying but surmountable - given that you are already interacting with the user,
you can probably figure out some hamfisted way of determing which URL to send them to.

But the next step is totally opaque.

The user authorizes access, and is redirect to your redirect_uri.  Your redirect_uri
is given a single parameter ("code") for the next call to "authorization_code".

In other words, your redirect_uri page is given zero indication of whether the given
code is used in the sandbox or not.

The only solution is to try to the "authorization_code" on the production URL, and if
that fails, cache the error & try the sandbox URL.  If that works, great, you know
it's a sandbox situation.  If try #2 fails, you now have two errors, and you need
to arbitrate amongst them to decide which to bubble up to the user.

 

(Note there is a totally nasty hack to guess sandbox vs. production - you could
look at the HTTP "Referrer" header, and hope that it's present & correct, and
then perform some mapping by which you hardcode that "cs4.salesforce.com" is
sandbox but "na3.salesforce.com" is production...  I do not count this is a
robust solution)

Given that the entire point of "login.salesforce.com" is to provide a single
"front door" that then tells you which actual domain to use, why don't sandbox
logins use the exact same front door?  Using "test.salesforce.com" for logins
means that client apps that wish to support the sandbox are needlessly complex.

Edit: it is possible to pass a "state" parameter to the oauth login page, and that will get passed back

to the redirect_uri, so one can detect sandbox prior to sending the user to the login page, and then

encode that knowledge into the "state" parameter so the redirect_uri knows.  It's a solution for this

particular case, but in general having to decide ahead of time on the "front door' endpoint means

that everyone who does an integration has to cart around extra data about each oauth token

(ie, whether it is sandbox or not). Still seems like a design bug.