Our platform offers you a vast library of tools which you can use to solve your business challenges.

As you can imagine, with such a large toolkit there are going to be things which that you never touch or may never use. Even veteran FLOGRAMMERS continue to learn new things.

This section is devoted guiding you to share more common approaches to FLOGRAMMING tips and tricks which will help you get to the best, and most efficient solutions.


Course Material


Our platform offers you a vast library of tools which you can use to solve your business challenges.

As you can imagine, with such a large toolkit there are going to be things which that you never touch or may never use. Even veteran FLOGRAMMERS continue to learn new things.

This section is devoted guiding you to share more common approaches to FLOGRAMMING tips and tricks which will help you get to the best, and most efficient solutions.

Overview

With such a large library of tools at your disposal, it’s more important than ever to resist the temptation to “dive right in” to FLOGRAMMING.

Instead, the very first question you should ask is, “Can I do ‘X’ with my application?”. In other words:

  • Is there a connector available for my app?
  • If so, does the connector contain the actions I need?

When we build connectors - they’re often built for particular Use Cases. While apps can have very robust APIs we don’t build everything (all the actions) - we want to make sure we address valuable use cases.

Let’s work through an example of this to demonstrate the thought process involved …

Vetting Feasibility of a Use Case

Imagine that I need to build a FLO that leverages the Salesforce connector. Where would I start?

Let’s explore a bit and think about this in-product …

Let’s imagine that I have a Use Case where I want to - for example - want to kick off a series of events for my team when an Opportunity is Closed-Won. To make this more real - let’s say I want to notify my team via Slack!

  • First, what are the kinds of things that I can do with Salesforce?
    • From an Action level, let’s inspect the “methods” (or things we can do)
    • For example, I can:
      • Search records
      • Read Related records
      • I can even work with files or attachments!
    • These are all good hints on what I can do with Salesforce
  • From an Event level, Event Triggers
    • You’ll remember that Events differ from actions in that they initiate your FLO.
      • Note that the Event card is special and will have fewer methods by nature.
    • In Azuqua when we’re building an event trigger - whenever possible we’ll be trying to use Webhooks.
      • Why? Webhooks are - essentially - instantaneous!
    • When webhooks aren’t available or there’s another way - Polling Monitors
      • If you recall from other modules - Polling isn’t instantaneous (typically every 5 minutes)
      • Logic - in a nutshell - is to make calls to find records, figure out what last modified date is - doing a cross-check to see if there was a change - trigger event monitor if there is a change that needs to be surfaced
      • We can only have event monitors if API gives us a way to check against timestamps
      • Often - we come across apps that don’t have these timestamps (which means we can’t have a monitor)
    • Summary:
      • Take a quick look to see what the monitors are before you begin
      • What Use case can we support?
      • Are there limitations with the API itself?

I’m Ready to Build!

Often, people review the actions and events that we just discussed and say, “I have everything I need to build!” Seems natural that one would then just dive in and start building FLOs.

This is often the longer way to a solution because ou may realize that many design choices should have been made up-front (before you start to build)

Why?

  • You need to consider business rules
  • Think about what’s going to make the design better
  • There are many ways to build a FLO - some may be more efficient

Instead of building - your first step should be to write down your business process as workflow!

  • This can be as easy as taking out a piece of paper and a pencil and working through the details
  • Looking at action cards in tandem, you may realize that there are other actions to make solution work

Now I’m Really Ready to Build (Further Review)

Once you’ve thought through your process on paper, you should do further review in-app. In other words - take some time to do some testing with individual cards using sample data.

Testing cards will help you determine:

  • What are requirements for inputs to various cards
  • What’s returned (e.g. What are the outputs from the cards
  • An object? A list? Some peculiar format?)

In other words - you haven’t made assumptions. In this process you may discover that you need to build additional actions to make things work the way you need.

Also may do test on the whole FLO - because will have logged in Execution History to inspect!

Common Patterns in Connector Action Cards

Most connectors will give Read and Search Cards

Other general patterns in connector action cards:

Search Cards

  • Typically gives you the option of returning first or ALL results
    • Good if you need collection of data and you might need to use subsets of that data throughout the FLO
  • Typically does not result in an error if you search with an invalid, blank or null value.
    • Use this to your advantage in FLO design!
  • Typically allow you to search by one or more inputs (provided that the API allows it)

Read Cards

  • Use when you know you will have the Record ID

Function Review and Discovery

We’ve discussed the review and discovery process around Connectors, but what about Functions? An obvious question is, “How do I know what function cards to use in my FLOs?”

If you’re building out your FLO and know you need to do some manipulation, the first trick is looking at the output of a dataset.

For example … If you’re working with text (string) you navigate to the “Text” section of the Function Library. If you’re dealing with and Object, a List, and so on - there’s a menu item for that too!

We have a full module on Function Categories, so click here for additional tips !

Using the Search Functionality

Search function is really handy, particularly for new FLOgrammers!

Let’s do an example …

Say that I want to do something like find a portion of a piece of text - maybe a description or a filename - that contains something that I’m looking for.

Our search interface makes this easy!

  • We’ve made a point of including both professional and layman’s terms so you can more easily find what you want
    • For demo purposes, let’s use the word “portion” in the Text area
    • If I type this in search, I see that it returns a couple options (like Pluck and Substring)

As new user - we recommend that you take a moment just to skim through the functions and their descriptions.

Also - the Most Popular section is really handy to surface the kinds of functions that you’ll use more often.

Summary

Armed with information presented in this module, you should find FLO design to be more straightforward as well as efficient - particularly when working within teams that share resources!