Become familiar with additional apps and common modules

Transcript

By now, you’ve practiced with a couple different apps and a variety of modules from each app. In many of the walkthrough exercises, you’ve been working with the HTTP universal connector modules, Workfront of course, and tool-based modules for routing, iteration, and aggregation. If you turn your attention specifically to the app connectors or the modules that let you do something with data from a third-party service, think Google Sheets or Workfront, you begin to notice a pattern in the available modules per app. Depending on if you’re creating your scenario trigger or adding a module within your scenario, you’ll notice that most modules have a section of triggers, actions, and searches.

Triggers can be instant or scheduled. If they are an instant trigger, then the icon on the trigger module will appear as a lightning bolt. Instant triggers are waiting or listening for data to be sent to your endpoint, your trigger module, when an event occurs within a third-party system. One example here might be that you want a scenario to kick off every time a new project is created within Workfront. More is coming on instant triggers and web hooks in an upcoming course. Scheduled triggers will show a clock icon, and we’ve been working with these types of triggers up to this point. A scheduled trigger will run, well, on a schedule, and when you establish the schedule, the trigger will not wait for information to come in to execute the scenario. Rather, it will go out to retrieve information from a third-party system. On an established schedule, this trigger module would go into a sheet looking for any new row added. If it finds new rows of information, it will send that information back through the scenario. Note that the default schedule for any new scenario will always be a regular interval every 15 minutes, but can be changed in a variety of ways to fit the scenario needs. Once you move past your scenario trigger, you’ll typically only find actions and searches as available modules. Action modules perform CRUD operations, or create, read, update, and delete types of operations. It’s important to note that the list of available actions will be completely dependent on the platform API. Again, the available actions within an app connector are completely dependent on the third-party platform API. Because of this, you’ll notice that the different app connectors will provide different unique actions. Anything beyond a CRUD operation will require a custom API call, which you can typically find at the bottom of the actions list. If an action module was a person, you wouldn’t label it a polygamist. It might jump from relationship to relationship, but it’ll only be in one relationship at a time. Jokes aside, action modules only process one specific record at a time and will need a specific record ID as an input, which of course can be dynamic for multiple bundles or records passing through the scenario. Search modules, on the other hand, can be found at the bottom of the module list within an app connection. Searches can return zero, one, or multiple bundles of information depending on the search criteria set up and what’s available in the platform called. You can think of search modules as a type of iterator because of the variable number of bundles it will return and then send through your scenarios. When running a scenario which uses a search, you’ll notice that the number in the execution inspector bubble will simply be a one although it may return multiple bundles of information. The number that you see in the bubble doesn’t coincide with how many bundles were delivered. Rather, how many times that module was executed. After a search module, you’ll typically see an execution count on later modules, which can be your visual cue as to how many bundles were returned from that search. To combine those bundles back into a single bundle to continue passing through your scenario, you’ll have to use an aggregator module of some sort. Bringing this all back together. Remember that there are three main types of modules within each app connector: triggers, actions, and searches. Triggers will only be available when creating your trigger module. Actions are dependent on the platform API for the app connector and will only process one specific record at a time. Searches can behave like iterators, returning more than one bundle to pass through the scenario after it. And finally, actions and searches can be used as your scenario trigger and they’ll generally be run as a scheduled trigger. -