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?
Discussion posts and replies are publicly visible
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!
Thanks Greg, this would be very helpful if I could reference that example in the Community Edition, unfortunately I do not have access to it anymore and there seems to be a huge delay in regaining access to it.
When you say to be sure the context of your related action is properly configured, are you referring to creating a related action on the Parent Record Type object to create a Child record? I didn't even think about that but I see now that you mention it that if you manually configure it you can set that up. However, there is still something missing after I added the Process Variable that Mike mentioned above as it is still not passing the Parent Record ID to the Child when I test it.
If you are noticing a large delay in regaining access to your Community Edition, I would recommend reaching out to communityedition@appian.com for guidance. They may be able to help or provide additional insight.
The goal is to pass the data from point A to point B. Specifically, the primary key of the record you want. Below is a snippit of what I am referring to. Although, I did simplify the expression down to better illustrate the point. The image shows the Context of the Request Maintenance related action within the Vehicle Record Type object. Within the process model, we have 2 process variables - cancel and maintenance. The maintenance process variable is a Maintenance Record data type - so it contains the structure of all data points related to a maintenance request - including the vehicleId. In the image, you can see that we are "passing" a value into the maintenance process variable. Since the maintenance process variable has a Maintenance Record Type structure, we are explicitly defining the value that we are passing in. Specifically, we are passing in the primary key of the record (rv!identifier = vehicleId) into the vehicleId field wrapped inside the AA Maintenance Record Type. This tells the process exactly where we want the vehicleId to go.
Greg, can you show me the full screen where you pulled that image from?
That screenshot is from the Related Action configuration dialog, namely the "context" window underneath the "Process Model" selection.
Thanks Mike, that is what thought, but isn't this different than the process you were describing to me? Or was this part of that as well? I am having trouble putting all the pieces together. I added the process variable on the process model like you described, but that in itself didn't make it work.
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:
I understand completely the point of a related action, I'm just used to QuickBase where when you create a relationship between 2 tables, it automatically sets up the add child record functionality so that when you are looking at a parent record and click add child button on the form, it pulls that parent id into the child record, i never got to see all the underlying functionality that made that work. There were no process models to be made or configured.
I really appreciate you taking the time to lay all this out for me.
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.