Hello Raymond -

I can think of a few different ways to accomplish this but it depends on your use case:

A) If you do not need your field to update in real-time (meaning, as data on the screen changes, the comma separated list changes):

• Declaritive Lookup Rollup Summaries (DLRS) - DLRS would be the easiest solution for you.  There are several threads in the community that discuss DLRS so I won’t belabor the details.  To get you started, check out I’ve recently discovered “Declarative Rollups for Lookups”

B) If you do need the data to update in real-time then things get a little more complicated but you still have options.  The key for this scenario is that you need to listen and react to changes in multiple models.  I’m assuming that you determine that Brothers and Sisters are related because they are related to the same Parent.  If there is another way they are related, then you’ll have to modify the below options for that.  In short, you need to listen for adds/deletes to Parent and also adds/changes/deletes to brothers and add/changes/deletes to sisters.  Upon detecting the changes, you need to re-calculate the CSV for the corresponding records.  Think of this as a custom trigger or roll-up type of activity.

• Custom Formulas - Brooklyn introduced custom formulas and this is an ideal use for for them.  Unfortunately, we do not yet know what “features” are available with custom formulas nor how to use them (see this thread for more info on that).  Once we have that info and assuming there will be ways to indicate which types of “changes” and to what “Models, etc.” will trigger a re-evaluation of the formula, custom formulas would likely be a relatively straightforward solution for your use case.  If there is a way to specify which changes trigger re-evaluation, then a simple block of javascript can determine the CSV list.
• Custom Javascript - In this case, you listen for all the events from the models that we care about, then have those kick off a shared function that can calculate the CSV list for rows that are effected by the change.  For example, if a new sister is added to parent ABC, then when the sister parentId field was updated, you would calculate the CSV list for the Brother(s).

Hope this helps!

---

Barry, you are a God among Skuids. Thanks. I completely forgot about DLRS. I remember looking at it a year ago for other purposes, but didn’t implement. I’ll take another look. Thanks!

---

Happy to help Raymond, good luck!

---

Barry, I created my own Skuid solution. I forgot that I had already done something similar for another situation.
If you know the maximum number of children that a parent may have, then you can polulate a text field on that parent using Skuid actions with the names of the children using merge variables. Your merge variable has to reference the row number of the child query results, so you just string together Child0 name , Child1 name, Child2 name, etc…
I wanted them delimited by a coma, so I created a custom text field on the child called “Delimiter” and set it to default to “,” and made it read-only then built it into the merge so that only if there was a child record would a comma populate after the child record name.
I trigger the actions when a child is created or updated on the Skuid page where I do that sort of thing. I also trigger it as a model action when the parent detail or list pages load.
This makes sure the text field has fresh data any time a user may see it.
In my case, I did it for ten child record rows. If you may have unlimited rows of children, this method would not work, but if you can determine that the parent would never have more than 20 rows, for example, or if you decided you just want to display in comma separated format only the first 20 children, this works really well.
It also would not work 100% if you have people accessing the parent record from salesforce directly instead of through a Skuid page as the children would not get refreshed.

---

Hey Raymond -

Glad you found a solution that works for you!  

As an aside, we now have some limited information on how to use custom formulas.  Unfortunately, we don’t yet have all the information including if its possible (and if so how) to inform Skuid when a formula needs to re-calculate.  I’ve posted some questions here and here to try to obtain the answers.

With that said, there are two undocumented APIs exposed of off skuid.model.Model that would produce the results you need: 1) evaluateFormulaFields; and 2) evaluateFormulaField. If you used a custom formula and then were willing to accept the risks described here of using these undocumented APIs, you could simplify your solution.  Writing a custom formula function to build the comma-separate listed would be straightforward and a perfect use case for custom formulas.  The only hurdle is getting the field to re-calc when needed (which would be done using one of those APIs).  Just food for thought.

FYI - I just created https://community.skuid.com/t/add-support-for-programmatically-triggering-formula-fields-….  Vote it up if you’d like to see this happen!

---