A very basic guide to Jadu Connect case type development

Forms in Connect can be thought of both as actual forms for direct data entry, and also as database table designs.

All case types will have a Create form; citizens will not interact with Connect forms directly, rather they will complete a form which has been built in the CMS which will have its fields mapped to Connect as part of the CMS form Actions. In this respect, you can think of the Connect form not as a form itself, but as a database table specification.

It is our custom and practice for all Create forms to contain the same core fields - the Person field (which allows linking a case to a citizen's online account), the Address (Property) field (which stores the UPRN of the address which is then converted into a human-readable address), and contact details fields which have (standard contact details) as part of their label.

Unfortunately, in Connect one does not simply build a form by going to Edit or Create Form and adding fields on the fly there and then. Fields themselves must be created (in Settings -> Workflow -> Fields) before you can then add them to a form.

And then

It's vitally important to note that the field type matters when creating a field. A

• Checkbox is not a choice field, it is a simple single set / unset field, whilst a
• Choice field will allow you to specify whether the choices appear as checkboxes, radio buttons, a dropdown, or a multiselect dropdown. Never use a multiselect dropdown for anything - the person who invented the multiselect dropdown considered whether he could, he did not stop to consider whether he should. A
• Date and a Date Time field will be used to store, erm, dates, and datetimes, and a
• Telephone field will store a telephone number and an
• Email field will store an email address. A
• Text field is limited to 255 characters whilst a
• Text Area field is to all intents and purposes not limited. And finally, a
• URL field stores a URL.

'Why does it matter?', I hear you ask, 'why not just store everything as a Text Area and be done with it?', you follow up with.

Basically, the different field types have functional roles as well as being there in the name of keeping a tidy house. If a Connect Dashboard user is going to create filters (to see, for example, a list of all the bin lid sized potholes seen since May 3), then filters for field values can only be created on checkbox, choice, and date fields. If you are going to want to have Connect send an email as a result of a Rule, then it can only send emails to Email fields. And if you want a URL in the Timeline to be clickable, it has to be stored as a URL field.

Once you've created a field, it cannot be changed to a different type of field - all you can subsequently edit is the Name. This is why you can see in the list of fields a lot of Checkbox fields with *** DO NOT USE *** in the name!

Data from a CMS form which is to be mapped to the Connect form must match - if a CMS form tries to send 256 characters to a Text field, Connect will not accept that, and the case creation action will fail. For Choice fields the Values being sent from the CMS form to the Connect form must match exactly - if you try to send the choice value The Library of Birminham to the Connect value The Libary of Birmingham, again the case creation will fail. If you subsequently change values in the CMS form, you have to ensure those values are changed in the corresponding Connect form. This is doable, but faffy.

It is because making changes to forms and form fields is so faffy and risky in Connect that I advise that the first thing which is done when making a Connect case type is to create the CMS form first, and make sure the client has tested it thoroughly to ensure it meets their requirements before going on to work on the Connect Case Create form in any more earnestness that just the basic contact details capture mentioned above. Making these changes after the fact when the client has changed their mind will involve doing work; that's fine, we are here to do work, but it's better we do work that is continuing to develop the service than having to do work to deal with something the client forgot about that they only realised when they had something they could see.

You can also create forms which can be invoked by Transitions to add or update data relevant to the action of the said Transition. If these forms are going to be used only by staff members you can usually create them in Connect only without having to create them in the CMS too and map them, but if they're citizen update forms you'll have to also create them as CMS forms, and you may have to prefill existing data too.

Lastly, there's the special Connect form type, the Edit form. It's best not to see this as a traditional update form, rather it should be seen as a kind of 'for admin use only' form for editing data without invoking a Transition. At the very least, include the Person field on this form, in order to subsequently attach a Case to a citizen's online account if it needs to be attached and wasn't originally attached.