About Data Structures

Overview 

Data Structures represent and organize business objects for internal logic processes with other Designer Elements such as Flows and Rules. 

Data Structures consist of data fields detailing the data's properties, including their data type. An example Data Structure may be titled "Employee" with example data fields in quotations and Data types in parenthesis: "Name"(String), "Age"(Int), and "Work Email" (Email). 

Similar to other Decisions Elements, Data Structures along with their data may be imported/exported into other Decisions instances or external programs as a CSV file.

When to Use a Data Structure

During planning, consider the following questions when determining which Data Structure to use:

1. Are processes object-oriented (a noun) or functional (a verb)? Which is considered first: the information to be processed or the transformation processes? If it's the former, it is recommended to use a Data Structure. If it's the latter, the focus should be on building flows and reports to generate the same results instead of using a custom Data Structure.
2. What are the reporting needs, and do they involve more than process details? If user-defined data gathered and submitted in a Form should be included in a Report, then using Data Structure is recommended. 
3. How often does the data change, and does it need to track its history? If snapshots of data are required, for example, in a patient medical review process with a frequently changing condition status Form, it is recommended to save that Form's information to a database that maintains its history for reporting purposes.
4. Lastly, how much information needs to be handled? It is recommended to build processes in functional blocks rather than in one large Flow, which may result in a cumbersome amount of mapping for each of these individual variables. It is more efficient to create one Data Structure that contains all those variables.
   
   

Think beyond the initial scope of the process when possible: first capture the initial request details and then add later process details. For example, if there is an approval step, it might be best to capture additional information such as an approval or rejection comment also be written into the Data Structure.

User Defined Data Structures

Creating Custom Data Structures

In addition to Decisions' pre-built Data Structures, Designers may create custom Data Structures from the following schema types:

• CSV
• JSON
• JSON Schema
• XML
• XSD

Data Structure CRUD Actions

Designers and specified end users/groups interact with Data Structure through CRUD Actions: Create, Read, Update, and Delete, for easily updating data in Decisions. These actions are visible as steps for the specified Data Structure in the Flow Designer. 

Data Structure Name Space

When creating a Data Structure, Type Name Space under the Advanced settings allows Designers to configure the namespace of the Data Structure. By default, this setting will populate with the folder path to the Data Structure, such as "MyApps.[ExampleFolderName]". 

It is recommended to change this setting when working on large projects since this default folder path name will grow larger as the parent folder becomes further nested. Furthermore, multiple data structures with the same Name Space may exist. Changing the Name Space name may prevent future organization issues.

Recompiling Data Structures

When Data Structures are giving errors, one thing a user can do is try using the Recompile Data Structures Action.

1. Right-click on a Designer Folder, select Compile and then select Recompile Data Structures. 
2. A list of Data Structures that need to be recompiled or a popup window stating that All Data Structures are up to date will display.  If a list appears, select the Data Structures that need to be recompiled and then click OK.