Skip to main content

We have a need to show a table of Tasks with a primary function of assigning ownership. All of these Tasks have a WhatId of a Case, but using standard SOQL we can only see the “generic” fields of this relationship. If I was coding this I could use TYPEOF, is this something that is available another way in Skuid?

How do we show fields from the related Case (read-only) that aren’t part of the standard WhatId relationship on the Task (must be able to inline edit the Task)?


My understanding of TYPEOF, as of yesterday, is that this is not GA and has been 3 years since being introduced. That said, you can’t both display more than generic data on both objects and have functionality on the task. At least not without javascript. In theory you could loop through the tasks, grab the id of the whatid, query a case model with it, grab the fields you need, update a template field on the task table, then have all the data you need. A lot of unknowns at this point for me though. Skuid folks can answer those. You wouldn’t be able to do anything with the case data as they not attached to any model.


Ross - are you wanting to show the Case data in a Task table,  or do you want to show it in a Task Detail page. 

Lets start with Detail page: 
You can create a second model on Case. It will have a condition tieing it to the Task.  (Task WhatId = Contact Id)   Then bring in a second field editor onto the page and set up the Case data.  Use Panelsets to arrange the field editors to your liking. The advantage here is that the Case data is editable here. 

Now the Table: 
I don’t think Pat’s method will work without some javascript - simply because the case template will not necessarily know what task table row is in context, and therefore which row of the Case model to retrieve for the template.  But you can include the case data in a drawer or popup.  The row actions do carry context, which can be passed into a Case model as the value for a filtering condition. Look at this tutorial about using drawers to show related data.   It should give you what you need.

So I don’t think we have an optimal solution for the table instance (including the “distantly related data” directly in the table) but you should have something to work with.