The selected file /tmp/fileOALWQF could not be uploaded, because the destination sites/default/files/css/css_a91cd284035e73ba34d112bfed2f5a16.css is not properly configured.
  The selected file /tmp/fileop8JFw could not be uploaded, because the destination sites/default/files/css/css_de1aa27776f1462d2b0d83a80ce4b92d.css is not properly configured.

Actions are the things you want the computer to do for you automatically. These are commonly referred to as “rules” and were historically created using programmatic tools.

Actions are used any time, and every time, you want the computer to do something for you automatically. WorkXpress Actions may take the form of Control Actions (evaluations, loops, and schedules) and Execution Actions (actual activities that do something).

There is only one interface for creating or maintaining Actions, the Action Manager. Here you can setup Actions on any available triggering point or according to a schedule. All Actions are created inline. Except for scheduled Actions and Action sets, all Actions are created in context.

All actions process in a specific order. Some are as obvious as “save a value” or “send an email”, while others are less obvious, such as “open a page” or “make a soap call”.

“Actions” refers to one of the five fundamental Building Blocks “Action Type” refers to a specific class of Action, for example “Field-save” or “Layout-open page”. “Action” refers to the specific placement of an Action of some type into a firing position in the Action Manager interface.

Creating an Action refers to the act of adding an Action of some type into an application.

There is only one way to create an Action. First, navigate to the Application Manager Tool, probably by clicking an available Layout or Field Block in the Application Workspace. Second, click on the Block representing any event; on its flyout menu, choose “Add an Action” (or add evalution, or add foreach, etc.).

At this point, you may use the linked select boxes to choose the Action Type. Each time you change the Action Type, the settings for that Action Type will reload. By adjusting the settings and choosing the save button, the Action will be created and properly placed into the context of current events.

Actions do not have wizard questions.

Creating Actions does not create any automations. Conversely, Actions may be created by the automations of other Building Blocks.

An Action is always associated with the building block for whom it is a “local” or “global” action (see below). Placing an Action in the Action Manager will result in that Action being associated with an Item Type based on where it is placed. Actions may be associated with Layouts, Fields, Items, or Relationships.

Similarly, an Action typically requires context to function properly. That context comes from the Block for whom this Action Manager Tool was opened and may not be the same Block for which this Action is a local or global Action. Context and Item Association for an Action may be different.

Further, some Actions can change the context. For example, when a list of Items is passed into an Action Manager from a “Mass Action” button in Layout Type - List, the context is each of the Items passed. However if they pass through a “foreach” control structure, the subsequent context passed to subordinate action is that of a single one of the Items in the list, changing each time the loop is repeated.

Without exception, all Actions are named using a “subject” and a “verb”. With a few exceptions, the subject corresponds to the Block type that it acts upon. The verb always describes the actual activity that it performs. The possible subjects are:

• item
• relation
• field
• layout
• report
• 3rdparty
• evaluation
• foreach

Some Action verbs include:

• create
• delete
• recycle
• save
• display
• openpage
• openmenu
• runthisreport
• changed
• contains
• …and much more

Therefore, some Action names might be:

• Item Create
• Field Save
• Report SendAsEmail

Actions can be placed in a “schedule”, in a “set” for external reference, or on an “event”. Most Actions are placed on an event. Events are specific activities that occur during normal usage of the application by a user, as described in the Action Manager. Wherever possible, every effort has been made to expose all possible events to the builder to maximize the builder's ability to influence the user experience with Actions.

Some typical types of events include:

1. Block is being validated
2. Block is being saved
3. On Click
4. On Mouseover
5. On Load

Actions may be associated with an event and block globally, or they may be associated locally. A “Global Action” exists everywhere and every time the Action's parent Block undergoes that same event. A “Local Action”, however, only exists when the Action's parent block undergoes this specific event, in this context. In this case though, context refers to the context of the triggering Block within the interface, not the Item context. This is a unique kind of context.

In other words, although a Field may trigger a local Action when it is saved from within one Layout, it will not trigger that same local Action when it is saved from within a different Layout. In both cases, however, its global save Actions will be triggered from either Layout.

For example, for a certain Field, Action A is global to its “Field Save” event for all pages and Action B is local to its “Field Save” event for a specific page. Later, that same Field is added to a new page. When that new page is saved, Action A will fire, but Action B will not exist at all on that page (in that unique context).

Execution Actions refer to specific activities performed by the computer, such as saving a value or sending an email. However, one subset of Actions is a Control Action. WorkXpress has four types of Control Actions:

• Evaluation - used for setting up an “if, then” scenario.
• For Each - used for repeating a subsequent series of Actions on each item in context
• Schedule - used for setting a time or series of times to run Actions later
• Thread - used for spinning off subsequent Actions into their own processing thread

Control Actions are treated like Actions in every way, except how they are treated in the Action Manager interface. Control Actions essentially serve to control, route, or group Actions, or to change their context. Execution Actions, on the other hand, exist to perform functionality automatically.

Events and Actions are always processed from top to bottom in the order in which they appear in the Action Manager.

“Actions Sets” refers to the creation of a group of Actions out of context that can be referenced and provided context at a later time by an Action that is running in context.

“Action Schedule” refers to the time-based firing of Action Sets. The Action Schedule is designed to give the Action Set context, if the Action Set is not able to produce its own context.

All Action settings are accessed simply by editing the Action itself, inline, in the Action Manager tool. Click on any Action, and then click on the edit wrench associated with the “edit action” menu choice.

Settings vary based on Action Type. Please see each individual Action Type for a detailed description of its settings.