Hi William, You are correct, this is what currently happens — we have not (yet) created a separate renderer for ‘COMBOBOX’ DisplayType fields, such as Task.Type, on account of the fact that this field DisplayType is only available here, basically, and not on any other fields, and you cannot create Custom Fields that have this DisplayType. So, for the present, we are just rendering ComboBox fields as text inputs. If it is very important to you to replicate something similar to the Salesforce picklist behavior, we can mark this as a Feature Enhancement Idea request, and hopefully get it onto our road map. Regards, Zach

Zach, I don’t know if it’s related, but Type currently does not display if added to a custom calendar popup.

Greg, check the Field Level Security on the Event Type field — this field is often not visible by default, and as such would not show up in a calendar popup.

Yes turns out to be the same for Task.Subject. Is there a workaround with a custom render snippet before you have this fixed?

Yeah, the Calendar “Subject” has the same issue. I am using it as my calendar Event Source Model Filter. I.E. Is it a Medical Appointment, Meeting, etc. When it just shows up as a text box people can accidentally make it so it doesn’t show up on the calendar by typing some miscellaneous subject. Or even if they know it has to be correct if they type it incorrectly by even one letter it can cause a problem. It would be helpful if it forced them to pick a subject from the list. Should I just remove subject and create a custom field? Is Subject used elsewhere that will break integration?

Skuid does not use Subject in ways that would be problematic if you didn’t use it.  It may be a required field in salesforce that may be hard to get around easily,  but I’m sure there are ways to achieve your Calendar model source behavior that don’t cause problems to your users.  You are on the right track…