FSL Mobile Flows – Creating Parent and Child Records

This post was originally featured on forcePanda by Narender Singh.

Picture a scenario where you want to create a Parent record and Child records in the same Flow.  For example, you want to create an Account and Contact in one Flow, or a Product Request and Product Request Line Item at the same time for FSL (as we will look at here).

Screen Flows allow us to create an SObject variable for a new Parent Record, and to use the Id from that variable in the Child Records you’re creating.  If you Insert the Parent Record first, then the Children can be inserted without fetching the actual Parent Id created in the previous step.  This lets you get more done with less queries, but unfortunately it is not (yet) possible, in the same way, for FSL Mobile Flows. See important highlighted note below.

Typical Assignment of Parent Id to Child Parent Id

Important Update: Salesforce flow team have in the last couple of days identified the bug with the FSL Mobile Flow and they are working on the fix. In the interim the approach below can be followed, OR you can insert the Parent record with mapping within the Create element (not using existing sobject variable) and store the output Id explicitly. This will work to map the child to parent in the interim. So if you’re building new flows, you’ll want to consider if you can do it this way (definitely feasible for simple flows). I would definitely recommend this if you have to build immediately and cannot wait for the bug to be resolved. For existing flows, you’ll want to consider the time required, and regression risk incurred, to adjust flows to take advantage of this workaround. I believe for most situations it will make sense to wait for the bug to be resolved and then eliminate the query logic.

Create Parent Record with declarations in the element and store the output.

If this approach works for your use case, or you can afford to wait until the bug is resolved, then go ahead and skip the rest of this post. For my part, I will still share it just to agitate myself further about all the work wasted in the past couple years 🙂

Original Method – Query for Parent – Hopefully this will not be Obsolete approaching going forward!: For FSL Mobile Flows, we need to follow a different approach.  Let us walk through how to accomplish this same outcome, even though it is quite a bit more involved.

First, we create the Parent Record – a Product Request for example.  We want to include on this Parent Record insert some field value(s) that will form a unique key that we can use to query for it later.  It’s critical to be able to identify and pull the parent, and not some similar record.  Oftentimes just filtering the later query by Status and then sorting by CreatedDate descending will do the trick, but we need to think through this depending on the business scenario.

Additionally, we want to think about what should happen if the Parent record is inserted and then the Flow is exited prior to any insertion of Child records.  I will often create the Parent record in a ‘Draft’ or ‘Cancelled’ type state, so that if the Flow is exited then there is no clean-up work required.

Draft Status for Parent

Second, we need to ensure there is enough time for the Parent record to sync to the server so that we can query the newly created Id.  For this reason, we should insert the Parent as soon as we can in the Flow, and then follow the process for building out the Child records.  In some cases, you’ll want to insert Screen Elements that are basically just slowing down users.

Third, we will perform the actual query to get the Parent Record by filtering and then limiting to the first record found that meets this criteria.

Query for the Parent Created

Fourth, we assign this newly fetched Parent Id to the Child records that we have already assigned.  If it’s a single record that’s easy enough, but if you have multiple children in a collection then you’ll need to loop through that collection and assign the Parent Id.

Assign Parent Id fetched to the Child

There we have it – now we’re good to insert the Child records as they have the required information.  Here we’ve demonstrated for Product Request and Product Request Line Item, but this approach obviously will work for any Parent/Child relationship.  This picture gives a quick outline of the process.

Make sure to review carefully the highlighted section above where Flow team have provided another workaround, and consider what makes most sense for your scenario.

Summary of Flow Steps for this Parent/Child behavior

In the next and final part of this series, we’ll take a look at a bunch of other tips and tricks accumulated while building out a full featured FSL Mobile implementation!

Leave a Reply

Your email address will not be published. Required fields are marked *