Overview

 

 Advanced 

 

For developers, Actions are a platform to build customized solutions for InFocus and support both SQL and Powershell. Below are a few examples of the kinds of solutions you could build using Actions.

 

•Interact with a third-party system. For example, trigger an export to a project information management system whenever a project is created, or pull in information from a web-based time-tracking app.
•Simplify multi-step processes. For example, InFocus comes with a “Refund Retainer” action. Run it, specify who and how much and you’re done. Use one of the many built-in Actions or create your own and then put it on your Dashboard for quick access.
•Add warning prompts for specific business rules. For example, “this time sheet isn’t over 40 hours, are you sure you want to submit it with overtime?”

 

Heads up! Developing Actions requires knowledge of SQL and/or Powershell

 

 

Framework

 

Actions operate on a three-part framework that includes: Parameters, a Script and Return Types.

 

Parameters

 

Each Action collects a set of parameters which are then passed to the underlying Script. Parameters can be fed in programmatically (e.g. from InFocus) or sourced from end-user prompts.

 

Programmatic Parameters

 

Automated Actions pass two primary parameters: AppletName and KeyID.

 

•AppletName (nvarchar) - Name of the InFocus Applet initiating the Action
•KeyID (int) - The ID of the record loaded in the respective Applet

 

For example, if running an action to suppress zero-hour timesheet rows when the timesheet it saved, InFocus will programmatically pass the following

appletname='timesheetitems', keyid=[record id]

 

Prompts

 

Prompts can be used to collect parameter inputs from the end-user. Displayed in a modal window, prompts are configured with the following properties:

 

•Prompt Style (Settings tab) - Sets the style of prompt (e.g. Single, Tabbed or Wizard)
•Prompt Type (Settings tab) - Sets how information should be organized within the prompt (e.g. Stacked, Horizontal)
•Sections/Steps (tab) - Defines the sections of the wizard and can optionally validate input
•Manage Parameters (button) - Parameters are configured and assigned to each section/step as applicable. Actions support an unlimited number of parameters.

Once a prompt has been completed by the end-user, the Action will pass the entered parameters to the Script for processing.

 

Passing Parameters

 

Regardless of how parameters are collected, they are passed to the script at execution. As such, the script will need to include syntax for receiving the parameters passed. For example,

DECLARE @appletname nvarchar(250), @keyid int

-- Get the Applet and Record ID

-- Parameter syntax = '^parameter^'

SELECT @appletname='^appletname^'

SELECT @keyid='^keyid^'

 

Scripts

 

Scripts process the actual tasks of the Action. Supported query types include SQL and Powershell and are entered in the Query window via Custom Reports (UT>Custom Reports). While not required, as a best practice, Scripts should include a Return Type.

 

Return Types

 

When processed, Actions trigger system responses to a defined list of Return Types. An Action can return zero or more return type result sets. Each result set can trigger one response based on the columns present. If more than one return type is returned, the system will respond to each item in the order returned. Powershell is it's own type of Action.

 

If an Action is in process (e.g. On Save, On Create, On Delete) and you want to break out of that, the query must raise a SQL Error so that it actually errors on the client.

 

A full list of return types is listed in our reference under Return Types.

 

 

Additional Considerations

 

Using SQL RAISEERROR

 

When processing Actions, it’s worth noting that while Return Types define the output of an Action, they don’t necessarily reflect the output of the event that fired the action.

 

So, if an On Save action errors out, the On Save event that fired it still occurs. For example: If you created an action to email Time Approvers after a submitted timesheet is saved (On Save) and the action errors out, the Timesheet is still saved. If you want to make your event contingent on the success of the Action, the Action must include an explicit SQL RAISEERROR (severity 11) which would then rollback the event.

 

Next up: Actions - Hello World Tutorial