As Force.com consultants working mostly in the custom cloud, we spend a lot of our time implementing and integrating multiple FinancialForce solutions such as Professional Services Automation (PSA), FinancialForce Accounting (FFA), Revenue Management and Supply Chain Management (SCM).  As we build these composite solutions, we are expected to keep them simple to implement, simple to administer, and inexpensive in terms of time, data storage, and other key resources.  This is an exciting time to be doing so because continued innovation on the part of both Salesforce.com and FinancialForce.com is now dramatically breaking down barriers that previously stood in the way of using “clicks not code” to build solutions under certain scenarios.

To explain what I mean, while keeping this account concrete, I want to focus on three technologies, all relatively new, which are responsible for boosting the power of “clicks not code”. These are, in no particular order:

• FinancialForce ClickLink
• The Declarative Lookup Rollup Summaries (DLRS) package
• Force.com Process Builder and Flows

Figure 1: The Basic ClickLink Data Transfer Patterns or Scenarios

ClickLink is conceptually a simple package, but delivers a lot of power.  FinancialForce and other vendors rightly focus on providing suites of solutions that target different areas of the enterprise, rather than one huge monolithic solution.  This being so, we need to ensure that solutions can “talk to one another”.  SCM sales orders need to be able to feed into PSA projects and FFA invoices; PSA billing events need to be converted also to FFA invoices; revenue recognition transactions need to be converted to FFA journals, and so on.  ClickLink allows configurable, code-free processing in such scenarios by automating several transfer patterns between Force.com objects.  The patterns enumerated by the ClickLink online help file include: copying one header-and-lines structure into another (e.g. sales order header and lines to PSA project and milestones) [Scenario A]; and auto-grouping of records on insertion (e.g. grouping billing event items into groups for invoicing together as one line) [Scenario D].  As a refinement of the header-and-lines copy function, ClickLink also allows synchronization, whereby subsequent changes in the source are propagated to the target in order to keep it up to date [Scenario E].

I mentioned grouping of billing event lines (items) above, but auto-grouping would not be much use if the lines could not easily be rolled up to the new grouping records and, unfortunately, there are sometimes restrictions on managed objects whereby we cannot use Rollup Summary fields. Enter DLRS, an open source declarative rollup package available on GitHub. It was written by Andy Fawcett, the CTO of FinancialForce. We have successfully used a combination of ClickLink and DLRS on a number of occasions to provide grouping of PSA billing event items into invoice lines in ways not envisaged by the authors of PSA.  Many clients have quite rigorous requirements for the granularity of invoice lines . In days gone by this would have required apex code to achieve.

Figure 2: A Simple DLRS Rule to Roll up Billing Event Item Amount to a Grouping Record

Thirdly, there are Process Builder and Flow.  Process Builder is relatively new, and provides an alternate, graphical, approach to Workflow.  (The capabilities are broader than Workflow, though, so don’t be misled by this comparison.)  Flow has been around for some time, but its unattended operation aspect has gone through a couple of incarnations recently, having first been made available via the Flow Trigger beta program, and now released into General Availability in the Salesforce Spring ‘15 release as a type of action that can be invoked from Process Builder.  Process Builder and Flow, both separately and even more together, are very powerful, and I cannot do justice to their full potential here.  For now, I will confine myself to giving an example of a case where combining Flow and ClickLink enabled a problem to be solved in a configuration that might otherwise have required reimplementation in code from scratch.

Many of our clients need us to automate the way their PSA projects are set up from upstream “documents” such as sales orders or opportunities.  Although there are often family resemblances between project set-up rules from one professional services organization to another, at a detailed level the variety of requirements is endless.  One of my clients asked that we create the following from each sales order (and services line item) in SCM:

• One PSA project
• One PSA budget on the project
• One PSA project completion milestone on the project
• A set of standard project tasks linked to the project

I was able to deliver this feature using ClickLink alone, by using Scenario C to generate many different line types on many different target objects.  The rule was invoked by clicking a button on the sales order detail page.

Then came the final requirement that threatened to break this design entirely.  They asked for a two-level hierarchy of project tasks instead of a flat list.  ClickLink (reasonably) restricts its scenarios to two levels of hierarchy, so something drastic had to be done to meet this new requirement.  I could not just tack on a third level of rule within ClickLink itself.

I decided to continue to invoke ClickLink from a flow and generate a flat structure of project subobjects, then, in a subsequent flow element, “fix up” the project tasks based on their work breakdown structure codes (01, 01.1, etc.) to automatically place child tasks under their respective parents. The flow itself was very simple, as shown in the following diagram.

Figure 3: Flow to Call ClickLink then “Fix Up” Child Project Tasks

The ffirule__RuleServiceActionRunRule element calls a brand new component in ClickLink version 5, which is a Flow Plugin that uses the Apex @InvocableMethod annotation to expose a method callable by Flow. It takes a ClickLink rule ID and a source object ID as input parameters and returns the target object ID as output.

Figure 4: Setting Parameters on ffirule__RuleServiceActionRunRule

The FixUpChildTasks flow element is called after the ClickLink rule has run, so it can “fix up” the project task’s parents as described previously. Incidentally, the FixUpChildTasks element was implemented a couple of different ways, and ended up in Apex because it was difficult to perform all the processing necessary using only Fast Lookups, Updates, and sObject collections. (As of now, it seems unclear to me how to perform such processing efficiently in Flow without the aid of such features as maps or the SOQL "in" condition in the "where" clause. My flow version of FixUpChildTasks did run and produced correct results, but exceeded the SOQL query limit when let loose on any but the smallest collections of project tasks. I needed to bulkify my flow, but without maps or an “in” condition on Fast Lookup it seemed impossible.)

The main point here is that instead of abandoning the original solution and probably rewriting it entirely in Apex, I was able to combine the technologies to exploit what each of them individually does well: declarative data transfer performed by ClickLink, and integrated invocation of different executable elements by Flow.

To amplify this point, there are numerous other common use cases that can be realized using a similar combination of Flow and ClickLink, where ClickLink by itself cannot provide a full solution. One example comes from the Services Resource Planning (SRP) managed package available from FinancialForce. SRP provides a set of standard integrations between PSA and FFA. One feature included in this package is a “Create Invoice / Credit Note” button on the PSA billing event object. Unlike a standard ClickLink button, this one has the intelligence to call the rule to convert a billing event to an invoice if the balance is positive, and to call the billing event to credit note rule if it is negative. Flow provides an opportunity here. By wrapping a flow around the ClickLink calls, and embedding a decision, it will be possible to invoke the invoice and credit note rules selectively, depending upon the sign of the billing event balance, while still allowing the user to click just one button on the billing event.

Because these solution technologies synergize so well, they hold out hope for us and for our clients that we shall have to resort much less often to the relatively expensive approach of customization in Apex or VisualForce and, instead, will be able to build quite sophisticated solutions declaratively. It really does seem as though a new era of “clicks not code” is dawning.

References

[Scenario A] etc: These are documented in the FinancialForce ClickLink help file.  Figure 1 is adapted from these scenarios.
[DLRS] The GitHub URL for the package is https://github.com/afawcett/declarative-lookup-rollup-summaries.