{{:​yellow_block.gif|}}Use Actions to build any Automation or Integration.

+

+

{{:​then_else.gif|}}

+

+

+

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.

+

==== Actions ====

+

{{:​yellow_block.gif|}}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.

+

+

=== What You'll Learn ===

+

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

+

- Ordered List ItemWhat is an Action?

+

- How are Actions triggered?

+

- What is a procedure?

+

- How do I create or invoke an Action?

+

- What Action Types are available in WorkXpress?

+

+

=== Triggers Fire Procedures, Procedures Execute Actions ===

+

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.

+

+

== Triggers ==

+

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.

+

== User Triggers - Page load, interface, and save triggers ==

+

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:

+

{{:​save_actions.gif|}}

+

+

== Computer Trigger - Scheduled trigger ==

+

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.

+

== Procedures ==

+

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:

+

+

{{:​user_saves_1.gif|}}

+

+

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. ​

+

==== Actions ====

+

~~UP~~

+

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.

+

=== Creating New 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:

+

+

{{:​user_saves_2.gif|}}

+

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:

+

+

{{:​action_email.gif|}}

+

+

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

+

+

{{:​user_saves_3.gif|}}

+

+

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

+

+

+

=== Invoking Global (existing) Actions ===

+

+

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:

+

+

{{:​action_report.gif|}}

+

+

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

+

+

{{:​action_report_2.gif|}}

+

+

You can see how our original procedure would then change:

+

+

{{:​user_saves_4.gif|}}

+

==== Action Types ====

+

~~UP~~

+

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 ===

+

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

+

== “If-then” Evaluations ==

+

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>​."​

+

== “For-each” Loops ==

+

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:"​

+

== “Run Later” Schedules ==

+

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.

+

== "​Thread now" ​ ==

+

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.

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

+

== Layout Actions ==

+

These Actions open pages, refresh Layouts, and more.

+

== Report Actions ==

+

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

+

== Email Actions ==

+

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.

+

== Webservice Calls ==

+

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.

+

== Google Maps ==

+

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

+

== Amazon Flexible Payment Services (credit card gateway) ==

+

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.