This year at Dreamforce, the theme was “together” and the most impressive technical innovation was how polished you could make digital marketing campaigns and community sites. In the past, it seemed like Salesforce marketing tools were more efficient than beautiful. Now they are both.
Check out the keynote starting at around 1h:10m with Brett Taylor. He will demo how Louis Vuitton is using Commerce Cloud and Einstein to build personalized phone apps with digital assets stored in their central content management system. I’ve played around with some of this in the labs and it is really cool.
I’ve been working with Salesforce.com since 2005 and I’ve made a few eyebrow raising comparisons over the years…
Salesforce is like Microsoft Access on the web. It lets IT Admins create applications that scale.
Salesforce is the least powerful, most expensive on-demand platform in the world.
Here is the crazy part. I meant it all as a compliment! Salesforce figured out early on that regular business people, not software engineers, are the ones who know their business best. Giving non-developers the ability to customize or even create applications is worth a lot to a profitable company. Hence Salesforce costs more in every dimension (per user, per GB, etc.) than other platforms.
Wait, not every dimension. I’m betting that total cost of ownership (TCO) is lower on most Salesforce.com apps. If you’ve got a problem that fits the Salesforce UI paradigm, then it definitely saves money over Amazon or Google App Engine.
The most recent example is Salesforce rolling out Lightning (Aura framework) capabilities with a super secure container configuration called LockerService. This is great news because it prevents less skilled developers from accidentally creating security holes.
So when comparing TCO for on-demand platforms, make sure you are taking into account security, implementation, and support costs. You’ll be surprised how cost effective Access for the Web can be.
Salesforce.com Content is a pretty good document management system. If you are using Salesforce and you aren’t using Content you probably should.
Uploading large quantities of files is not difficult, but requires some local knowledge. Here are a few tips to make it easier.
- Give the Apex Data Loader more heap space. Instructions can be found here.
- I like to err on the side of reliability when doing document uploads; so I change the Data Loader Settings to use a batch size of 1 and do not use the Bulk API.
- Keep in mind that you can only import 5,000 files per day. If you are doing more than this, open a case with Salesforce.com support and get the limit raised temporarily.
- Files in Content are managed by 2 objects. ContentDocument and ContentVersion. When uploading new documents to Content, you are adding records to ContentVersion. When you are bulk deleting, you delete records from ContentDocument.
- The easiest way to figure out how to create a ContentVersion upload file is to first do an Export. Make sure to manually add a few files to Content through the UI so there is something to Export from each of the Libraries you want to populate. When doing the ContentVersion Export, select ALL columns EXCEPT VersionData. VersionData contains the actual bytes of the files in Content.
- The minimum set of columns required for a Content import are:
- TITLE = User friendly name of the file, can be anything, but usually the filename without any folder (path) information.
- PATHONCLIENT = Fully qualified file name including ALL path information.
- VERSIONDATA = exactly the same as PATHONCLIENT.
- FIRSTPUBLISHLOCATIONID = Salesforce ID of the Library where the document should be loaded. If you don’t put this in the file, then your files will be uploaded to your personal library which must be wrong.
That should get you started. Have fun assembling your files into batches for uploading. Once they are in Content, you’ll get the benefit of secure sharing, preview of popular file types, and flexible tagging.
I’ve been having a great time in the Wayland Barn doing data migration work with MS SQL Server 2012. The gigantic legacy database I’m moving to Salesforce.com is super speedy on my SSD so everything is good.
Until I find out that that legacy database has triggers and stored procedures written with a deprecated JOIN syntax. They are using *= in a zillion places to perform OUTER JOINS. and the rain starts pouring in Wayland. Truth is, that syntax has been out of style for a decade. But Microsoft was still supporting it until just this newest release. Check out this very good summary of the situation.
I’ve been working on a Salesforce.com data migration recently and I love it when they improve the platform in subtle yet powerful ways. My most recent pleasant surprise is the expanded length of “Name” fields. Names used to be limited to 80 characters, which seemed generous, but still left us with a hack for storing legal names on some objects (tables).
Now Names can be up to 255 characters and it is a great simplifier. So with joy and gratitude, I’d like to ask Salesforce to do something way easier. Please enhance the best on-demand report writer and allow us to show/hide totals and grand totals in matrix reports. This idea has been floating around for years and I can’t imagine it being difficult to implement.