WE have rolled out FinancialForce HCM, fka Vana HCM. In an rather conventional move, we did our development in a sandbox, and deployed our changes to production.

Most of the deployment was regular run-of-the-mill workflows, a few custom fields, and maybe a validation rule or two. Nothing worth writing about, until I tried deploying the permission sets.

FFHCM manages all permissions in a permission set. We had 3 permission sets to deploy, all of which were custom permission sets, but they referenced manage fields in managed objects.

I had no idea what I was in for. The FF folks came up w/ an interesting solution for deploying field and object permissions. These can be deployed in a data job, as these exist as data and metadata at the same time. I’m not sure how an update would work, but for the create it was quite straightforward. See the 3rd post on this success thread for...

With headless flows making their way to pilot, and hopefully production by summer, my mind has been tinkering away on what I will do w/ them.

I just received confirmation that the flows will run in system mode, like a workflow rule, which adds many possibilities. For example, presumably the flow should be able to update a field on the running user’s user record.

This would allow triggering a notification the first time (and only the first time) a user does a specific action. Simply create a checkbox for every action you want to measure, say creating a lead. Create a workflow rule which fires when the lead is created, with criteria of: $User.Has_Created_Lead__c = FALSE. That triggers an immediate email to the user that says “hey, nice work, way to create your first lead,” and it also triggers a headless flow that updates the checkbox to TRUE, so that it will never fire again.

Now...

With 400 users across 20-odd countries, I am always looking for ways to make them more productive and efficient.

While much can be done at the role, profiles, and permission set level, at times the customization needs to be at the user level, and cant be generalized to a higher level of abstraction. Pulling this off without adding huge administrative overhead is possible! Read on…

We use an object that hangs off opportunities to allocate the total amount by program and location. Salesforce is not the system of record, but this object is key to dividing our pipeline across various programs and countries, and therefore these “funding links” are used by each and every country, and most people end up using the same set of codes most of the time.

So I wanted to allow each user to have a default set of codes, so that they can quickly create a record using their own personal default...

1. Subtab App allows users to define personal “default” values that are used when creating a new record
   

2. Custom “Dynamic Funding Link” button creates record with default values as specified in subtab app
   
   

Next posts:

• the button
• the controller
• the visualforce page (simple)
• the visualforce page (Complex).

[update : captains log june 18 2020. summer20 release. its a lot easier to use a flow that runs in system mode to do most anything that requires a without-sharing apex controller]

As custom controllers can run in system mode, unencumbered by such niceties as security restrictions, I reasoned that I could pull together a custom visualforce page that users could go to which would allow them to set the values of fields on their own user records, that otherwise they would not have access to. I cannot say that this is definitely a good idea. I am not a coder and did a lot of reading, guessing, and borrowing to bring this code to life. To see the final product, go to this link

A couple of books I can recommend are The Visualforce Cookbook by Keir Bowden and Development with the Force.com Platform by Jason Ouellette

I went for an extension on the User object, because it seemed to make...