RPM Software

When working with the API you may have noticed that the way Fields are specified when adding or editing forms is a bit different between fields inside tables and outside of them. The way fields are provided inside tables differs in two big ways:

1. Identify the fields inside tables by their Uids – ProcFormAdd and ProcFormEdit use the field name (via the “Field” key) to identify which field to fill. This works because field names are unique inside the process. But for tables we have switched to Uids, this reduces the potential for confusion and makes finding the correct field on the server side a lot faster.
2. Allow multi-value values – for fields outside tables we provide the value using a string, this becomes a problem when working with multi-select fields because it requires special formats which are error prone. For fields inside tables we’ve moved to a more structured way of providing the value of the field via an array of objects. Multi-select fields are not supported inside tables at the time of writing but this structure should allow to add support easily.

These two are differences make the API easier to use and understand, but because we didn’t want to disrupt current API users these changes didn’t get implemented for fields outside tables. Due to that we have 2 ways to specify fields in the API which can be confusing.

This guide will clarify a bit the differences and more importantly will show how to work with fields inside tables. The example section contains a full example of how the data is sent.

ProcFormAdd basic structure

The basic argument list for ProcFormAdd is:

ProcFormAdd(    int    processID,    string Process,    object Form,    bool WebhookEvaluate )

The Form object contains a Fields key that is the list of fields to fill in:

If a field is a table field, instead of having a Value key it will have a Rows key:

Rows

The data structure for rows on a table field is very simple and the only difference is how to identify rows when working with a defined rows table. To identify the defined row a “TemplateDefinedRowID” must be provided, the value should be the ID of the defined row as received in ProcFields.

Deleting rows

To delete rows from free rows table you must exclude the row from the data payload sent to ProcFormEdit.

When working with tables it’s recommended that API users first fetch the form’s complete data using ProcForm and then modify the data inside the tables to ensure that untouched rows do not get deleted by mistake.

Fields inside row tables

Similarly to the Form, each row has a “Fields” key with a list of fields to fill in but the structure is different:

• Identify the field by Uid – as of this writing (RPM20) the fields are identified via their name outside tables but for fields inside tables we use Uids
• Provide the field Value with an array – each entry in the Values array will have a “Value” or “ID” key:
  • Use “ID” for fields that options with IDs (This IDs are available via the ProcFields API endpoint for list fields, or for reference fields via the different endpoints based on the reference type – i.e. ProcFormList, AgentUsers, CustomerUsers, etc.)
  • Use “Value” when the field has free text values (dates, text fields, number fields, etc)

Example

This section shows a sample process (via ProcFields) and an example ProcFormAdd request to show a set of fields inside tables.

ProcFields

ProcFormAdd request

Conclusions

We’ve written this guide to clarify the differences of the data structure for fields inside tables against fields outside tables. Here are the main points:

• Providing data to ProcFormAdd and ProcFormEdit requires the user to send a list of fields along with their values to fill the form
• The data structure for fields inside tables is different than for fields directly on the form
• The structure for fields inside tables is a future proof form that will eventually make it to the fields outside tables
• When sending data for a defined rows table the data requires to identify the row to fill via the TemplateDefinedRowID key
• The value for fields outside tables is provided as a string and the value for fields inside tables is provided as an array of objects that vary depending on the type of field (some take an ID key and some string Value key)

Related API endpoints

• ProcFields
• ProcFormAdd
• ProcFormEdit