One of the challenges you get when you have a special snowflake org is lots of people want to write lots of reports and lots of dashboards for each of their special use cases. Now, lots of times reports aren’t the right way to go with this so you have to educate your users on the right way to do this and their old reports get abandoned. Or a user will create a one off report and never look at it again. As it stands right now, we have several thousand reports that haven’t been looked at in more than 90 days.
A while ago, someone posted on the developer boards a question about how to bulk create tasks for contacts via REST. I thought it was an interesting enough problem to cover how to do it and how to format the data correctly to use it.
Before we can bulk create tasks for a contact, we need to know how to identify those contacts. To do this, I create an unique external Id field called External_Id__c. As long as your contacts are uniquely identifiable then it doesn’t matter what field you use. For this example I have two contacts under different accounts “Andy Young” with an external Id of “ayoung” and “Edna Frank” with an external Id of “efrank”
After updating the Case object to API 38.0 I didn’t notice that the Case.Type field had changed. In API 37.0 this is what the Case Type field looks like
<fields> <fullName>Type</fullName> <inlineHelpText>The case type</inlineHelpText> <picklist> <picklistValues> <fullName>Value 1</fullName> <default>false</default> </picklistValues> <picklistValues> <fullName>Value 2</fullName> <default>false</default> </picklistValues> <sorted>false</sorted> </picklist> <trackFeedHistory>false</trackFeedHistory> <trackHistory>false</trackHistory> <trackTrending>false</trackTrending> <type>Picklist</type> </fields>
And this is what it looks like in API 38.0
<fields> <fullName>Type</fullName> <inlineHelpText>The case type</inlineHelpText> <trackFeedHistory>false</trackFeedHistory> <trackHistory>false</trackHistory> <trackTrending>false</trackTrending> <type>Picklist</type> </fields>
In the turmoil of all the other changes to the object file, I completely missed the change. And when the deployment failed I was at a loss to figure out why. The failure wasn’t about the picklist in particular, it was about the picklist value in a record type.
One of the problems I had with the way that we generated the PDFs in previous Battle Station Invoice posts was that the table header wasn’t repeated for long lists of supplies or resources that continued on the next page. There’s a simple way to add the table header for PDFs generated in Salesforce using the flying saucer mark-up but that won’t generate the table header correctly for us. It seems that the
-fs-table-paginate tag does not play well when combined with a Visualforce component so we’ll need to take a bit more of a native CSS approach.
NOTE: If you are doing this with plain Visualforce and apex:pageBlockTable, the -fs-table-paginate is the way to go.
Like many companies, we have a deployment process in place to handle changes in seasonal releases in Salesforce so that when a sandbox is ahead of production, we can still deploy to both without having to wait for production to be updated. Then, after both the release hits production, we go through a manual process of updating the API (primarily the ant-salesforce.jar) and the metadata to the most recent API version. Typically this just involves updating the jar and updating the API version in the request, pulling down the updated metadata and writing it to SCM. However, with the Winter ’17 release we saw a problem trying to deploy our GlobalPicklist files after updating the API.
There are lots of times where working with Salesforce would be so much easier if it weren’t for the users. But, they’re the reason I still have a job, so you’ve got to put up with them. One of the problems with users is they tend to like to live all over the world and they all have their own ways of working and cultural eccentricities. One of the ones that has caused us grief in the past (both in Apex and in reports) is the fact that Japanese users in Salesforce default to “Lastname Firstname” when using the Name field on Users. Now, this in and of itself is not really a problem because lots of reports are written for a single user or for a relatively small group of users (such as others in the same geographical location). Where this becomes a problem is when locales get mixed with reports and all hell breaks loose.
This will be the first time I’ve written a post like this, so if it’s terrible, I’m sorry. This post will be not related to Salesforce work at all so don’t feel obligated to read it if you’re expecting Salesforce stuff.
2016 marks the 3rd year that I’ve participated in the Tuna 200 and the 5th time I’ve done a endurance relay race. I thought I’d take a moment to record how this year’s race went, what worked well and what I would change for next year
In an effort to try to reduce the amount of code in our base repository we’ve been looking at writing managed packages that we install in our production org and then delegate the development and maintenance of these packages off to other teams. Being a Open Source company we also want to try to offer what work we’ve done to other people. However, not everything we want this package to do is useful outside of our business. To solve this, we’re releasing the base package and then creating a private child package to hold most of our business logic and custom fields.
So it’s been a week since the end of Dreamforce 2016 and I’ve had some time to soak in what was talked about. This year my task for Dreamforce was to go and get some pretty specific answers. So, instead of talking about everything that happened at Dreamforce and what I think about it, I’m going to talk about the three things I was tasked with looking into.
With the recent updates to the licensing model at Salesforce, lots of companies now get Live Agent licenses included. Because of this I’m working on a hands-on training for how to setup Live Agent and use it in Service Console. As you could guess, this isn’t an quick thing to do so I’m splitting it up into parts.
One of the hardest parts of Live Agent to test out for non-developers is the actual web front end part. If write the HTML locally and then you can test it but others can’t. To make it so others can test it, you either have to set up a web server or figure out how to deploy it to a cloud provider such as Heroku or Openshift. And that can be pretty daunting for someone that’s just trying to setup a proof of concept or is just working on the configuration side and will pass it off to someone else from their web team.
What does the quickstart provide?
The Live Agent quickstart I wrote provides a super fast way to deploy a Live Agent button to Heroku. Once you have set up Live Agent, you can copy and paste parts of the configuration into the first screen of the Heroku app setup and then click deploy. After a couple of minutes you have a website that anyone can goto and interact with your chat button!
Similar to the entitlement process hands on training, I’ll be publishing it to github for everyone to use (and fork if desired). It’s going to take some time since it’s a lot of brand new content but I’m hoping to have it done before the end of the year. So, follow here and at the github repo to keep informed of it’s progress.