Layouts are the forms you present to your users. Create rich pages and navigation.

Fields are nested in Layouts, and let users enter data about Items.

Forms on a webpage take a variety of shapes and sizes, and as such there are a variety of Layout types to choose from. The most basic Layout is a “page” itself. Within a page, you can nest other Layout types including Field Grids, Lists, Calendar’s, Tree’s and much more. Within a Form, actual data is presented and captured in a Field.

Fields are similar to a form element or a control (in addition to filling a role in the data layer). They serve the primary purpose of presenting data to and capturing data from Users. However, they also incorporate user interface elements such as input masks and sub-controls like a calendar picker or color wheel.

Items are the people, places and things you want to track.

Relationships connect Items together.

Fields collect and store data about Items.

To create a usable application, you'll need to build a robust data model. A data model is a diagram of the people, places, and things you want to track with your software application, what information you want to track about them, and how they are interrelated. In WorkXpress, Items, Relationships, and Fields comprise the data layer of an application and are the Building Blocks you'll use to realize your data model. This first lesson will teach you the key WorkXpress concepts you'll need to know to begin constructing your own data model and will get you thinking about the people, places, and things you want to track with your application.

Defining an Item Type is conceptually similar to creating a table. However, WorkXpress Item Types are more like meta data that describes multiple tables, which in turn describe a business concept.

WorkXpress Relationships are similar to one to one, one to many and even many to many relationships. In truth, they more like meta data that describes any of these connection types. In fact, you can even store data on a WorkXpress Relationship, or connect multiple relationships of the same type to the same two records.

Creating a Field and associating it with an Item Type is very similar to adding a column to a table. However, a Field in WorkXpress does double duty by serving both the data layer and presentation layer. Further, WorkXpress Fields include additional concepts such as Field Parts, which are themselves effectively additional columns in a table.

Use the Search Builder tool to Query the WorkXpress data layer. You can Query Item Types, “join” across Related Item Types, and filter using Fields. All manner of branch logic, filtering and connections is possible empowering a diverse query capability very similar to a SQL language, except point-and-click.

Use Actions to build any Automation or Integration. We'll teach you about the fifth and final Building Block of WorkXpress, Actions, in this lesson. We'll examine the different kinds of triggers in WorkXpress and show how each trigger fires a procedure. For any procedure, we will show you how you can create and invoke Actions. Finally, we will list the different Action Types available for you to use in WorkXpress.

We'll teach you about the fifth and final Building Block of WorkXpress, Actions, in this lesson. We'll examine the different kinds of triggers in WorkXpress and show how each trigger fires a procedure. For any procedure, we will show you how you can create and invoke Actions. Finally, we will list the different Action Types available for you to use in WorkXpress.

After completing this lesson, you should be able to answer these questions:

1. Ordered List ItemWhat is an Action?
2. How are Actions triggered?
3. What is a procedure?
4. How do I create or invoke an Action?
5. What Action Types are available in WorkXpress?

The purpose of a trigger is to fire a procedure. The details of the procedure can vary greatly based on the specific trigger that fires it.

A procedure executes Actions. The types of Actions available at any point in a procedure will vary based on the type of Block from which it is launched.

In WorkXpress, you must tell the computer when to perform an automation. A trigger is the mechanism that is used to communicate a need for automation to the computer. There are two types of triggers, those fired directly by a user, and those fired indirectly by the computer.

When working in an application, there are, at a high level, only three different things a user can do: load a Page, perform activity within a Page, or save a Page. These three general types of activities serve as triggers that can generate automation. Specifically, these three user-fired triggers are called Page Load, Page Interface, and Page Save triggers.

Any interface element can serve as a trigger when loaded, used, or saved. For example, a specific Field can trigger a procedure, as can any Layout.

A User Trigger, then, is any Interface Element (Layout, Field), which is loaded, used, or saved.

The illustration below shows the different types of triggers available from a particular interface element:

The only other event, outside of a user activity described above, that WorkXpress could interpret as a trigger is the arrival at some specific point in time. Setting up these points in time is referred to as scheduling. By creating Actions that are scheduled, you are authorizing the computer to run those Actions according to information in the schedule you provide.

All Actions are executed as part of a series of chronologically ordered events called a procedure. If we diagram that procedure, we expose the order in which those events occur. Procedures move from the top to the bottom of the diagram and process each event in order. The starting point for any given procedure will vary based on the trigger, but an example is shown below: In this example a user clicks the save button on a page, thereby triggering the “page saving” procedure for that page. First, the Item the page is about begins to save; however. In order to complete, it must save the page it is on. In order to save the page, each Layout must save. In order to save a Layout, each of its Fields must save: Field 1 saves first, Field 2 second, and Field 3 third.

In WorkXpress, an Action is anything you want the computer to do for you automatically. Actions are executed as part of some procedure that was fired by a trigger. As part of a procedure, you may create Actions to send emails, update task statuses, open new pages, or even make SOAP calls.

To reiterate: a trigger fires a procedure. A procedure may or may not contain Actions.

When building an application, you may create an Action to be placed at any point in a given procedure. Lets re-examine the procedural tree we diagrammed above:

We'd like to create an Action that sends an email when Field 2 saves. We can add that Action to the procedure as follows:

Now that we've added our Action, let's see how our diagrammed procedure has changed:

As you can see, that Action has become a part of the procedure and will be executed when a user saves that page.

When an Action saves, creates, or deletes another Item, Relationship, Field, or Layout, it invites that Building Block to in turn run each of its global Actions as a part of this procedure. Those global Actions may have been configured somewhere else in the application. In fact, all Actions placed on any Item, Field, Relationship, or Layout event are automatically assumed to be global Actions and can be executed from anywhere else in the application that impacts that Building Block.

For example, if our Action in the procedure above was intended instead to “Save a value in a Field”, the procedure would need to invoke that Field and any global Actions already associated with that Field. Let's suppose there exists elsewhere in the application a Field 4, and that Field 4 already has a global Action to Run a Report, as below:

Then, if we create an Action that happens to save a value into Field 4, we invoke its global Actions.

You can see how our original procedure would then change:

There are a wide variety of Action Types available in WorkXpress; however, not all may make sense for any given trigger or procedure and may not be accessible for that trigger or procedure. Below is an overview of WorkXpress Action Types and their function.

Control Actions serve to group or manipulate the flow of Execution Actions.

Use these to create decision points. “If <you choose something to evaluate against something else> is true, then do <some actions you choose>, otherwise do <different actions you choose>.”

Use these when you may have a context of multiple Items but want to perform actions on each Item individually. “For Each <use inherited Items or choose a different set of Items> do the following Actions:”

Use when a set of Actions should be performed at some future point. “Run the following Actions at <you set a time>”. These Actions will be placed in the Actions Queue at the appropriate time.

The thread option is similar to “Run Later” schedules above, except that it simply takes the entire child procedure and puts it into the Actions queue, freeing the procedure to continue. Use threads when you don't want your users to have to wait for some Actions to complete.

Execution Actions create automation that performs specific tasks for your users.

Create, delete or recycle Items.

Create or delete Relationships.

Use the Expression Builder tool to pull data from the database and save it to any Field.

These Actions open pages, refresh Layouts, and more.

Create reports; display them on screen, or save them as a file. Use the email actions to email them to a distribution list.

Use these Actions to manage email on an MS Exchange or IMAP mail server. Scan the mail server for emails meeting certain criteria and import them into WorkXpress, using subsequent Actions to attach those emails to related items. You may also use these to send mail or delete it from the server.

Use 3rd party actions to make any webservice call using WSDL technology. Choose the webservice, define the information you want to send to the call, and tell it where to store the results it will send back to you.

Use 3rd party Actions to leverage the great things you can do using Google Maps.

Use various Amazon FPS Actions to quickly accept credit card and other forms of payment within your application. Best of all, using this method you never have to receive, store, or be responsible for private credit card information.