FinancialForce + JIRA: Lessons Learned
I finally got a chance to take a client live with the (relatively) recent JIRA/FinancialForce Hub Integration, so I wanted to jot down a few lessons learned while they are fresh in my mind.
Know Your Target
The integration is a bit different depending on whether or not you use JIRA Cloud or On-Premise JIRA. Specifically, authentication is handled differently - API authorization keys for Cloud vs a traditional user / password credential for on-premise. That said, I ended up in a difficult situation, as the customer was using Tempo for timekeeping in JIRA. This ended up being wholly incompatible with the Hub Integration when used on the cloud, for technical reasons I won’t get into here (ask me if you’re interested).
In a similar vein, there are two major approaches to using the connector. One uses a fairly straightforward 1-1 relation between a JIRA project and FinancialForce project. An alternative use involves mapping a FinancialForce project to an Epic (effectively a single issue) in JIRA. Configuration options vary widely depending on your choice.
Assignment Selection
One of the more interesting problems the integration has to solve is how to pick the correct assignment for the timecard it is creating. After all, a Resource could conceivably have multiple overlapping timecards for the same period.
To address this, the integration uses a checkbox on the Assignment called, “Use for JIRA Sync”. If checked, that particular Assignment will be used. Make sure only one Assignment has this checkbox selected, otherwise an error will be raised.
So, what if you have Resources logging time with no Assignment, and you wish to continue with that model? In that case, select “Allow Timecard with No Assignment” on the project and you’ll be good to go.
Sad face: all your timecards will get no assignment in that scenario, so be prepared to write a bit of automation to select the correct Assignment (that’s what I did).
Error Handling is Solid
The error handling is pretty good, for an integration. All the errors I encountered were highly verbose and even contained recommendations on how to resolve the issue. On that note, one of the immediate issues I ran into involved the aggregated worklogs on the JIRA issue exceeding the maximum space available on the timecard Daily Notes fields.
Watch Out For…
Indeed, this issue seems like it would be universal to almost anybody using the product. Everyone knows more than a few people that ‘hyperlog’ or log a variety of tickets - maybe 8 or 10 even - in a single day. With the integration, each note will be compiled into a singular text string that will inevitably exceed the maximum length of, say the “Monday Notes” field, which is only the Salesforce-standard 255 characters.
Surprise! The documentation uses this exact problem as an example of how to remap fields.
You Can Remap
Consistent with FinancialForce’s previous integrations, default field mappings are overridable, so that’s nice. You can map your JIRA issue fields to where ever you’d like on the timecard. I didn’t experiment with custom fields on the JIRA side, though.
To solve the issue previously noted, you’ll need to remap the worklog notes field to a more sizable field in FinancialForce. As mentioned, the documentation uses this as an example, so you’re in good hands.
It’s Fast
Did I mention it’s fast? Seriously. Timecards come over in a minute or two, and often almost instantaneously. Combined with the solid error handling, this makes configuration problems (say, for example, a missing Project in FinancialForce) quick to detect and fix, before large amounts of logged time gets missed.
No Replays
Unfortunately, unlike the integration my client replaced, failed timecard attempts do not go into a ‘replay’ bucket where you can try them again. Any errors need to patched manually. Oh well, nothing is perfect.
Overall, this is a great tool for shops that are heavy users of JIRA, but don’t wish to saddle their developers with having to deal with yet another timecarding system.
