Hey Matt -

Unfortunately, there are some things going on in your app/code that aren’t shown in the video (eg. what is the value of datarow in the call to makeCase) so it’s difficult to say exactly what might be going on here.

One word of caution on the approach you are taking here is that the following scenario could occur:

1) User opens Drawer for Row #2 - Condition gets set to ID of row #2
2) User opens Drawr for Row #1 - Conditions gets set to Id of row #1
3) User clicks create new button inside of drawer for #2 - Row will (should) be created for Id of row in #1 since that was the last time the condition was set

Given this, you likely want to change your approach to not rely on the model conditions and instead, explicitly set the appropriate value to ensure that the new case gets created against the correct patient.  To do this, grab the Id of the row in context and apply it in your additionalConditions property in the call to createRow.

Now, all that being said, the strange behavior you are experiencing is a little concerning.  It could be a skuid bug or it could be something in your code.  Difficult to say without more visibility to your code, etc.  If you can put together a repro of the scenario using standard objects I’d be happy to throw it in to a DE org on my side and take a closer look.

Thanks, Barry. Your word of caution was instructive. Grabbing the row in context and manually setting the value along with the rest of the additionalConditions was an easy fix.

Not sure if there’s any kind of bug here, but if there is, it’s probably something unique enough to not bother with.

Glad the change in approach resolved things Matt.  As for the strange behavior/bug, if you decide to circle back and try to isolate, let me know.  There definitely is a problem there (either skuid side or custom code) and it’s likely to manifest itself again.