Approval processes are hard to transfer between orgs because this Support packaging and migration of approval processes feature is missing. To document approval processes I have been taking screen shots of the diagram view that is available:
That view also has a more complete printable view – diagram and documenting tables with cross-referencing numbers – but no built-in “export as PDF” of that view. The salesforce help suggests the work-around – install a printer driver that can output a PDF file. (I wish I had found this work-around a few weeks ago, hence this post to publicize the approach.) The printer driver I am using is the Pdf995 Printer Driver. And Mac users already have the required functionality without installing anything.
So now I have PDF files that at least document the approval processes and so allow them to be a little more more easily re-created in different orgs.
Just wasted another chunk of time on a Force.com site.
Everything was fine by the time the development work was finished. But when set up for a demo the site just output the “is down for maintenance” page. Now I understand the idea of not exposing internal site problems to customers. But here there was no additional information reported – no debug log entry and no email to the “Site Contact” User – an exceedingly poor design choice. (And yes I did add the automatically created “Site Guest User” to the “Monitored Users” for debug logging.)
So what was it this time? I eventually found the answer in this post Force.com Sites and licensed managed package in LMA. As well as being a managed package, my package has licensing configured. Now I had looked at the normal license UI accessed via “View Installed Packages” and did not see any mention of “Site Guest User” so had made the bad assumption that sites were probably not “license aware”. But it turns out (as detailed reading of the post will tell you) that the UI to associate a license with a “Site Guest User” is well hidden and must be used to allocate a license before the site can use the package.
The fix was quick and it all makes sense. It was just way harder to find than it should have been.
Just spent a couple of hours trying to figure out why one page of a Force.com site was not working. That page – unlike some other working pages – makes use of apex:column components to display SObject fields. This suggested a problem with profile FLS or CRUD settings. For sites (that allow anonymous access) these are managed via a special profile accessed via a “Public Access Settings” button. But after numerous checks and re-settings the fields refused to appear.
An atypical characteristic of this particular site setup is that the objects, classes and pages are in a managed package installed in the org. With several of the site pages working, I had paid no attention to the package installation. But the problem was that the package had been installed but not deployed. As soon as it was, problem solved.
The lesson is that when using a managed package always double check that the package has been deployed by confirming that the “Deploy” button is grayed out.