Creating a child record from the parent record interface.

Question

I have a Parent Summary interface that I want to add a record action button to that creates an entry in a child table. Adding the button is easy enough, however adding that button alone doesn't connect the Parent to the child when using the button. So what steps am I missing to make that connection?

Mike Schmitt · Answer

Lots of detail is missing here. What does the button "do"? Generally a related action will launch a process model, but what have you configured / tried within this process model? What information are you passing in? At a minimum I'd hope you're already passing in the primary identifier information (in whatever form), though it's unclear what else you might be doing here to create the child (a user form? a fully automated process? something else?).

Mike Schmitt · Answer

In the most generic sense: the process model would have a PV (set as a parameter) in which you'd pass in the parent primary key ID. From the user's perspective, when set up correctly, it would be as simple as clicking the button (then filling out any required extra fields/etc). Is there anything in particular you're having trouble with here?

Mike Schmitt · Answer

This refers to the simple action of adding a PV, which I assumed the basic training covered.

Mike Schmitt · Answer

cls5469 said: This should be done in the Process Model for Creating the child record correct? 
 Yup. 
 cls5469 said: What should go in the Value field? 
 Nothing. A pv being elected as a "parameter" implies that the value will be supplied at run-time. In this case you'd pass it in as process context in your Related Action configuration.

Greg Wheeler · Answer

Hi cls5469! 
 Let's explore this from the use case example in the Acme Automobile Reference Application, available on your Community Edition Site. Users should be able to request maintenance on a vehicle. They would achieve this by going to the summary view of the specific vehicle they want to request maintenance on. They would then choose the related action > Request Maintenance. A process would kick off that would pass the vehicleId into the process from the record. This is done in the Context of the related action within the Record Type object. This is important as this is how the vehicleId gets attached to the maintenance request. By the end of the process, a Write Record smart service writes the data to the maintenance table. 
 Be sure the context of your related action is properly configured to pass the primary key of the record you are on, into the appropriate field in your process to be part of the data that will be written. 
 Hope this helps!

Mike Schmitt · Answer

That screenshot is from the Related Action configuration dialog, namely the "context" window underneath the "Process Model" selection.

Mike Schmitt · Answer

cls5469 said: I added the process variable on the process model like you described, but that in itself didn't make it work. 
 You need to understand the entire construct and, well, point , of a related action here. 
 Basically a Related Action's purpose is to enable quickly calling a particular process model in context of a particular record entry to enable you to take some action on that particular entry. There are a few separate parts of this configuration that all work together. 
 The process model configuration is what we discussed above. In the process model, you need to provide the target for the context - i.e. the primary key ID (and, optionally, other pertinent details when necessary, which can also be added as Parameter PVs). But starting simply, just the primary key ID parameter PV is needed. 
 After and only after that is set up successfully, the Related Action Configuration (mentioned above) comes into play. That tells the system what in particular needs to be passed into the started process upon click of the related action when it's clicked (again, this would be when viewing a particular entry in your list). The Context will simply be a dictionary list that matches the configured Parameter PVs (or any expression / expression rule that outputs the same, which can be useful if/when it gets more complicated). That simply means the started process instance will be fed those values (relevant to the record entry the end user is currently viewing) instantly. This is spoken to in the Help Tooltip on the "Context" dialog, for what it's worth:

Mike Schmitt · Answer

The benefit to how it works in Appian, despite the extra work of setting it up correctly, is that you get much more flexibility (AFAIK) in how the work is accomplished. For instance, you could pass the parent record ID into the process and have the process auto-generate a related child record with no further work from the user. Or on the other hand (and slightly more likely), you could make the related action chain the user to a Task form where they enter certain required details about the child record - name, description, other settings, etc? Stuff that might not be easy (or possible) to automate? All done on a form. Then they can click "confirm" (or whatever label you want the button to have) to save to the DB, or they can click "cancel" and start from scratch later. It's all up to you.