Updating items from old to new is a recurring theme in most of our lives and for our connectors, the idea is the same! As we mature our connectors, there will be times where an older version of a connector is deprecated in favor of the new one. What can happen though is a card or functionality that was present in the old version may not be copied in its exact form to the newest version.
In this particular case, we are talking about finding the equivalent to the Workfront (Old) Get Collections card and how modify your FLOs for the newer version, Read Related Records. A customer who was working on migrating from WF (old) to WF (new) cards ran into this error and wasn’t sure how to achieve the expected results from the new card. The old card schema was setup like this:
With the older Get Collections card, your output was always a stringified array of objects. In order to process through the array you needed to first parse the string into an actual array of objects using the JSON Parse card, and then you could use a List For Each card to iterate through each object and perform the desired actions in a Child FLO.
With the newer Read Related Records card, you are able to pull back sub-objects that are related to a parent object as long as you have the ID of the parent object. However, you are not able to filter records on the card like what was available with the Get Collections card! The customer was concerned with this because they only wanted a list of tasks where there was a value in the roleID field of the task. They did not want to use a List Filter card and a child FLO to filter their list and they were otherwise unsure how to accomplish this task. Filter cards are not very performant by nature and often decrease the efficiency and run time of FLOs. That being said, there are two cards from the List Function category that are the least impactful and most efficient to use for a large majority of use cases: Filter by and Find By.
For this particular scenario we did not need to pull back a single record from a list but instead needed to slim down a list, so Filter By was our best option. Filter By allows you to filter through a lsit of objects by specifying a condition that must be met by the value at one path in the object. The path in question for the customer was roleID, and so we needed to filter the list to only contain objects where there was a value at the roleID key, which looks like this:
By setting our operator to “not equal”, we are telling the card that we do not want to include objects that have an empty value at the roleID key. This solution eliminates the need for a child FLO, keeps the number of cards used for the new solution the same as the number of cards for the old solution, and overall makes the FLO a little easier to digest and understand.
Stay tuned for more Ticket Solved! posts, there will be new posts each week! Of course if you have any questions regarding this solution or how to better use Filter cards, post to the community or comment on this post below. Who knows, maybe your use case will pop up next!
Customer Success and Sales Engineer