Over the past year, I have been working on a number of integrations using Jitterbit, focused on moving HR data to various systems.

We initially went for a transactional approach, where operations would be triggered by outbound messages. That turned out to not work well with the Netsuite API, without purchasing a rather expensive user license that would allow concurrent API sessions. However, at the time we needed to “throttle” SFDC outbound messages, which can contain up to 200 records at a time, so that they processed one record at a time. I’m recording how we did this here, as I’m sure I will need to reference it later.

Its quite easy to do, once you have created an web service operation to consume the outbound message (will post on that later).

The outbound message operation in Jitterbit has 3 components

1. Web service method
2. Transformation
3. Response

In order to throttle the...

We needed a dynamic approval process for our new HR system (FinancialForce HCM), where the 3 approvers for a consultant job requisition needed to be based on the budget managers for the related department, cost center, and region. Budget manager is a custom lookup field to user.

I quickly came across this article on developer.force.com and got ready to spin up a SOW to get some developers working on it. The code is needed to lookup a user on a reference object, and populate that user into the record being submitted for approval.

And then i realized that a flow could easily pull an ID from the user lookup on the parent record and dump it to a custom field on the child. However, I would need an apex plugin to kick off the approval process from the flow.

Back to the developers to build an apex plugin…

And then, whilst browsing the great cloud flow posts on salesforce yoda’s website...

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...