2

We have a trigger that inserts a Chatter Feed Item to a particular Chatter group when certain records are inserted, and we are passing in a value for the LinkUrl field to allow users to click the feed post and navigate to the record. We also want the users to be able to navigate to the inserted record from the Chatter group's email digest. Complicating matters is the fact that we restrict login access to an internal SSO portal with My Domains enabled.

I'm populating the LinkUrl field like so:

feeditem.LinkUrl = URL.getSalesforceBaseUrl().toExternalForm() + '/' + newRec.Id;

This seemed to work nicely at first, since this method returned our custom My Domain URL just as it should (something along the lines of https://my.custom.domain.salesforce.com). Unfortunately when inserting the records via Data Loader, this started returning https://na7-api.salesforce.com. I'd say it's not much of a problem except that now when our users hit this link, they are redirected to the standard Salesforce login page (which they cannot use, since we restrict their access to SSO and as such never generate a password for them).

So my question is two-fold: why does URL.getSalesforceBaseUrl().toExternalForm() return different results depending on how the records are inserted, and is there another method that I can use to fetch our custom domain?

Improve this question

2 Answers 2

Reset to default
4

The URL.getSalesforceBaseUrl() is based on the context that the code is running in. Since you are using Data Loader, you are using the API endpoint to communicate with Salesforce. I would suspect it would be even a different value in the context of a Visualforce page.

I'm not sure if it will work, but you could try creating a formula field on the object that builds the link and then reference that field in your trigger. I think this formula will give you the correct domain: 

LEFT($Api.Partner_Server_URL_260, FIND( '/services', $Api.Partner_Server_URL_260))+"/"+Id

Note: In Summer '13 release, the endpoints are changing and na7-api.salesforce.com will become na7.salesforce.com.

Improve this answer
1
  • I'll give this a shot, just seems like something that should be a lot easier than having to store a server URL on every record that gets created. Or I might just stick the trigger code in a @future method so that it's always being executed in the context I'm expecting. Commented Apr 30, 2013 at 0:25
3

The best solution for your problem is to not bother with the base url at all. The best value for the LinkUrl is:

feeditem.LinkUrl = '/' + newRec.Id;

This way in the very unlikely event you move servers, or change custom domains (I don't even know if that is possible) your linkUrl's are not dead.

For an explanation to your exact question, why is the getSalesforceBaseUrl different @DanielHoechst's answer is perfect.

Edit As mentioned by @JCD this causes issues with the chatter digest. Your other comment about moving all the logic into a future method could be a problem if you run out of future methods in a day.

My suggestion would be a custom setting holding your my domain url. It's not perfect I know, but personally I think it is better than needlessly using future calls.

Another less than optimal suggestion is a scheduled job emailing a custom "chatter digest" containing these created LinkPost's and the correct urls.

Another more radical suggestion is a script in the users browser (if using webmail) to process the links.

Improve this answer
3
  • I thought of trying that, but didn't want to go through the work of coding it. When you try it in the UI, it puts http:// by default. Didn't even occur to me to remove it! Commented Apr 29, 2013 at 22:39
  • Thanks @Daniel, I actually tried this method first. It works like a charm in the UI, but when users get the Chatter group digest email they just see a link to /somesalesforceid, and clicking on it gets them nowhere. Commented Apr 30, 2013 at 0:13
  • Thanks for your update, @Daniel. The custom setting or label with the domain URL might work as well. As you pointed out there is always the risk of going over the @future method limit, although we have just under 600,000 of those per 24 hour period in the org in question, and the inserts in question only happen in bulk every few weeks. Commented Apr 30, 2013 at 13:58

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.