Create rows in unrelated model from a modal

I have a page displaying a deck on model “programs.” A click interaction opens a modal that displays a table of eligible enrollees from another model (“contacts”). I’d like to add a mass action that will create one row for each contact selected in another model (“enrollments”) which will have the selected contact’s Id and the modal’s “program Id.”

I have tried several options:
A) On the click interaction (on the deck), I create a new row in a temporary model called “selectedProgram” which successfully prepopulates the id of the program. In the mass action on the “contacts” table, I specify create rows on my “enrollments” model and select the Program Id from the “selectedProgram” model, but it does not work.

B) I gave a unique Id to my modal “enrollModal” and tried using mustaches to grab the Id, but I must be doing something wrong, because I can’t get it to populate.

C) I tried selecting use a field from another model, but that always returns the first row, and I need the row in context of the modal.

D) I tried setting context on the “contacts” but there is no direct link to Programs.

It’s a little complicated, but the key to mass creating rows in another model is via a ui-only field that initiates a model action. For your example, I would create a ui-only field on Contacts called ‘CreateEnrollment’ that’s a datetime field now. When that field is updated, have a model action that creates a row in Enrollments with the ContactId = {{Id}}. With that setup done, change the Mass Action in the Table so it updates the CreateEnrollment field to NOW. Now when the Mass Action is run, it’ll update CreateEnrollment causing rows to be created for each Contact selected, with the Contact populated.

Program is a level further from context, so I would consider updating a ui-only field to Contacts called ‘ProgramInContext’ that you update for all records when opening the Enroll Modal. That way its available as merge, and you can populate it as you populate ContactId = {{Id}} as explained earlier.

Hopefully this helps!

Thanks! That’s very helpful. I was able to get the mass action to create the Enrollment records in the model with the correct ContactId. I have not been able to get the selected ProgramId into the record, however.

  1. I added two UI-only fields to Contact: CreateEnroll (datetime) and SelectedProgram (reference to Program sObject).
  2. I added a model action when CreateEnroll is updated to create rows in the Enroll model with default fields for Contact = {{Id}} and Program = {{SelectedProgram}} (I also tried with {{{SelectedProgram}}})
  3. On the Deck interactions, I added a Query model: Contacts, then Contacts: update rows setting SelectedProgram = {{Id}} (I tried {{{Id}}} here as well, but to no avail). (I added these two actions before the Show modal action).
  4. I added the SelectedProgram UI field to the table in the modal to see if it gets the value, but it does not, no matter what I try.
  5. The mass action works to create the enroll records with the correct (selected) contacts, but of course, the Program is not carried over since it’s not populated on the table.

I changed the UI-only field “SelectedProgram” to text and managed to get an Id populated in there. It’s the Id of the contact, which is why it won’t carry over to enrolls. I’m still stuck at getting the Id of the Program onto the record?

Ok, I got it to work. I added an action on the Interactions on the Deck to update Programs (UI-only checkbox called selected) and named the output. Then, in my action to populate the ProgramId on the Contacts model, I used the named output and took row 0 and Id field. Now it works as expected.

Glad you were able to get it working. This is one of those dark corners of Skuid that needs some dusting out.

Access to the Grandparent context has never been an easy thing. I often resort to create a “detail model” that is queried when you first open the Modal. It just retrieves the selected record from the list into its own model (with only one row) so you can use global merge syntax to pass the values into the new records.

That sounds intriguing. Can you add some detail on how to do that?

Ok here is a sketch. Based on your data model of programs, contacts and enrollments. (Classic junction object data model).

  1. Create a separate “SingleProgram” model that is limited to 1 record and has a filterable condition on Id. Query off.

  2. In the sequence on a program that queries contacts and opens the modal to create enrollees - you add an extra steps - passing the ID of program row in context into the filterable condition on that new model. And querying the model - (Mostly just to get the name value)

  3. In the Contacts table actions, when you create new enrollment junction records you can use row context to pass in Contact data, but you will need to use global merge syntax to pass in the Enrollment data. It will look something like this {{$}}.

Additional Notes about MASS ACTIONS.
One of the mysterious realities about actions is understanding what Row Context is currently active at each step in the action sequence. If you print {{Id}} after an action - which Row Context will pass that ID value?
When you create NEW rows - after the action is completed the context is transitioned to the new row. So the ID value will now be a temporary one. This causes a lot of consternation and we’d like to make this more explicit in the future (Safe Harbor and all that…)
This is most complicated in Mass Actions, where your sequence of actions is repeated for every row you had selected. The new row action (to create Enrollment record) captures row context, and then when you go to create the second enrollment you have lost the Contact Row context. Boo.
Here is a way to make this work.

  1. Your mass action should simply update a UI Only field - we usually use a date field and update its value to “NOW”
  2. A model action on “Update row” should fire a predefined action sequence.
  3. The action sequence should do the row creation in Enrollments.

Action sequences recapture the row context every time they fire, unlike the repetitive iteration of mass actions. We’ll fix this soon, but for now this is another way to solve the challenge.

1 Like