Tools Overview

The SimplyWork platform consists of a collection of tools used to create applications, including forms, tables, workflows, pay policies and timekeeping rules.

• Tables: row/column data storage
• Forms: user presentation for applications or ad-hoc use
• Application Builder: apps built from tables and forms
• Functions & Plugins: visual decision tree for all time-based rules
• Rules Engine: visual decision tree for all time-based rules
• Workflows: visual decision tree for managing business logic
• Events: launcher of workflows, triggered by data changes or scheduled events

The following outlines each at a high level. See links below each section for a more detailed review of the tool.

Tables​

Tables are buckets where you store like-data, say Expenses, Customers, Warehouses, Cost Centers or Projects. Tables follow a spreadsheet metaphor in that there are rows and columns, where rows represent the unique records in your table, and columns are the attributes of each record.

The Tables app is used to define the Fields (columns) that would exist in each table. Records (rows) are entries stored in the table (e.g. an expense report would be a row/record in the Expenses table.

Here is a hypothetical Expenses table for storing employee expense reports:

Fields​

The fields within each record represent the things you want to know about the record. In the expense report above, those fields are:

• Date of expense
• Description
• Category (for your GL)
• Where (the vendor, supplier..)
• Project (one of your projects)
• Who (who was with you)
• Amount

Data Types​

Each of these fields also has a Data Type which defines the type of information you can put into the field. Data types include:

• String (text)
• Boolean (Yes/No, On/Off, 1/0)
• Integer (whole numbers)
• Float (floating point numbers)
• List (list of strings)
• Date/Time
• Event (a special date/time used in calendaring)
• Location (a special field for capturing geolocation on mobile)
• Lookup (reference a record in another table, such as Projects)
• Image (copy of the receipt)
• Address (for geocoding places)
• Signature
• Files (for attaching documents or images)

When creating a new application, Tables are the first step in the design process as you need to define what data is to be captured and stored, and what the relationships are between data in related Tables.

Learn more about Tables in the Reference docs.

Forms​

Forms are the presentation layer to the users, and mimic paper forms. Forms can be deployed stand-alone--such as a survey, injury report or notification--or as part of an application which includes multiple pages, filters and other tools.

When creating a form, you connect it to a datasource, which is often a Table. You then add visual Components which in-turn connect to the underling Fields of the datasource.

Cards​

Forms contain Cards which provide navigable sections within the form. User input can be used to jump from one Card to another in order to create a logical flow and separation through the form.

Actions​

Buttons on the form provide Actions such as navigation (e.g. from one Card to another) or to submit the form. Validation of the data or other post-processing can occur by attaching a Workflow to the form. The Workflow accepts or rejects the form and also triggers other processing (see Workflows below).

Multiple Views​

Different Forms can be created which each reference the same underlying Table; for example, the employee's view of an expense report vs their manager's view. In this way, the components added to the form (e.g. Fields the user will see), Actions and Workflows might all vary based on the business process or policies.

Learn more about Forms in the Reference docs.

Application Builder​

Applications on the platform are compilations of a number of other resources into a user-facing app. Tables, Forms and other setup go into the publishing of an app, then Events, Workflows and other back-end processes handle the logic and behind-the-scenes tasks.

The construction of the application can include the following components:

• Views (main body of data)
• Resource (an optional parent datasource)
• Filters (limit records in the view)
• Actions (perform actions on the records)
• Forms (user interaction with a selected record)

The image below demonstrates the components assembled into an application:

Styles​

The first aspect of designing an application is to choose its overall Style. An Application's style depends somewhat on the underlying data, the target audience and desired end-result. The style selected determines the overall structure of the application and how users will interact with it.

Available styles are:

.	Style	Description
	Form	A wrapper around a stand-alone form; useful when users will simply fill-out a form which will be submitted into some process
	List,Map, Card, Task	A classic style where a list of records is displayed; clicking a row opens the selected record using a pre-defined or system-generated Form; alternate views include Map, Card and Task
	Scheduler	Date based application for displaying date sensitive data in a a spreadsheet format; examples include employee scheduling, time tracking, project management or any data with an Event field

Views​

Next, Views are chosen to present the data within the application frame. When discussing List style apps, List was really just one of several view types that can be chosen. The records of any application's current view set can be displayed in a any of the Views assigned to the application. The view style chosen depends on the type of data in the underly records, and the needs of the user.

.	Style	Description
	List	The most common form where records are displayed in a list, like a spreadsheet
	Card	Records are listed as cards, like a collage of business cards
	Task	Records are listed as cards in columns such as as task board; the columns themselves are generated by one of the fields in the record (Table); like a task board, cards can be dragged from one column to the next, updating the related value
	Map	Records are displayed on a map (requires a Location/geo field)
	Calendar	Records are displayed on a calendar (requires an Event field)
	Scheduler	Records are displayed on a weekly scheduler view (requires an Event field)
	DataView	A powerful way to create custom views of data, such as a pivot table using the DataView tool

Components​

Finally, Components are chosen based on the style of app and other required functionality. Below is a more detailed description of the components which may be included in each style of application:

Learn more about the Application Builder in the Reference docs.

Functions & Plugins​

While the proceeding sections discussed the user experience, the following sections cover the behind-the-scenes tools and components which control logic and business process. At the lowest level of the logic food chain are Functions and Plugins.

Functions​

Anyone proficient in Excel is familiar with the extensive functions available when editing a cell within a spreadsheet. Functions perform calculations on data within the current document and can perform specialized tasks. In Excel this is time value of money, math aggregation, date calculations and many others. The functions themsleves are not smart: you must provide the data, and they simply perform a singular task or computation on that data.

Similarly, Functions on the SimplyWork platform are used within Workflows, Rules Engine and other areas as the final mile of the no-code process: Functions are where the code lives. Functions are also extensible, such that we can add additional functions to handle new type of calculations or challenges.

The table below summarizes a few popular functions:

In the CAPITALIZE and LOOKUP functions above, other functions (ATRIBUTE and SLICE) are used as parameters; this demonstrates how functions can be nested within other functions

We'll see how Functions are called in the Workflows section below.

Plugins​

Plugins are specially developed code modules which handle logic which is highly specialized and exceeds the reasonable capabilities of Functions and Workflows. Plugins are especially useful for custom integrations to third party systems where the integration points are well known but potentially complicated: rather than recreate the logic using Workflows and Functions, a Plugin author can create the integration (or other business process) in code while still keeping its functionality compartmentalized.

When registered, a Plugin publishes it's entry points through Functions, so a Plugin is then called within a Workflow using it's exposed functions.

Plugins are maintained by the author and are installed as part of an Application published within the Marketplace.

Learn more about Functions in the Reference docs.

Rules Engine​

The Rules Engine is a specialized workflow tool for handling pay policies and time calculations. The Timesheets app uses a CALCULATE_TIMECARD function (by way of a Timecard Plugin) called from a Workflow to in-turn invoke rules on time data.

Decision Flow​

Rules are linear decision flows which apply calculated values, set exceptions and perform other tasks on time data. Here is a hypothetical layout for a time rule:

The rule logic works from top to bottom, branching to the right as test conditions dictate. A rule can short-circuit at any point in the process and fall out. Only at the end does a final decision (value) get assigned back to the data.

Each node in the rule flow utilizes Functions to make decisions or set values, so builds upon the capabilities of the published Functions.

Parameters​

Rules also include optional parameters, published by the rule author. These parameters allow a rule to be applied across many populations where the rule logic is the same, but the parameters applied to the rule may vary.

Many rules are pre-written to cover a variety of pay policies, such as:

• Rounding
• Schedule enforcement
• Overtime
• Shift premiums
• Gross ups
• Attendance
• Weighted OT
• Leave
• Holiday
• Day and Week attributes

Any pay policy challenge can be handled by simply extending the rules; simply create a new rule workflow, or copy/modify an existing rule.

Learn more about the Rules Engine in the Reference docs.

Workflows​

All business logic is implemented through Workflows. Workflows are the decision trees through which all data processing decisions are made. Workflows are triggered by events, such as a form submit, a database update (CRUD) or a scheduled event. The input to a workflow is usually a form, or a record being added to a Table.

Types​

Some examples of how workflows are used:

Workflows use Functions to perform the decision making and data updating. Functions are either decision based (IF) or action based (DO, SET) with endpoints (START, DONE, COMPLETE).

Flow Diagram​

Here is an example of a workflow diagram used with the Publish Availability app:

The workflow first checks validity of a number of fields, then loops over collected data, ending with the sending of a notification (which also loops).

Node Types​

Here are the available nodes within a workflow diagram:

.	Node	Description
	Start	The entry point into the workflow
	IF	A decision node which calls a function and returns Yes or No, usually the function in this node tests a value (e.g. IF(ATTRIBUTE(Employee,Exempt),1,0) which would follow the Yes path in the workflow if the employee is exempt, otherwise the No path)
	SET	Action nodes which call functions to set values, either into workflow parameters or data
	DO	Action nodes which call functions to just do things (no x=y, just z())
	LOOP	Loops over records in a data set; some prior SET would have created the data set, then the LOOP will chain over each row; the 'LOOP' path is followed for each record, then the 'DONE' path to continue
	WORKFLOW	Calls another workflow, the parameters and data of the current workflow are the inputs to the next, if the next fails, the parent fails
	STOP	Workflow fails and returns Deny if performing a validation
	COMPLETE	Workflow succeeds and returns Success if performing a validation

The ultimate end-game of a workflow is to either allow a form submit or calculate and set values.

Learn more about Workflows in the Reference docs.

Events​

Events are triggers for calling Workflows. Events are useful because there may be multiple forms which are submitting to a given table, and while each form could have a workflow for validation purposes, gaps may exist whereby a new form is created and--if the workflow omitted--data could end-up in a table without proper validation.

Events include settings for Triggers and Workflows; triggers determine how and when the event is fired; workflows are the executions which occur when the event is fired. When multiple workflows are listed, a failure by any one results in a failure of the event.

Triggers​

Events can be linked to the following trigger conditions:

CRUD Types​

For database updates, the following additional conditions can be set:

Its up the to author to decide where to place logic: validator workflows or events, and while there is no right or wrong, will simply be a matter of what makes sense in each situation.

Learn more about Events in the Reference docs.