Reference Contents > Manager Controls > Workflow Trigger Alert Maintenance
There are many circumstances where managers or other users wish to know that a particular circumstance has arisen or an event taken place on the system. This may be as simple as a part going below re-order level or a customer exceeding his credit limit. These circumstances, of course, can always be investigated using reviews or reports. However, this is not likely to be timely and is generally time consuming.
Workflow Alert Triggers is a feature in which events can be reported automatically direct to the person who needs to know either via the Message Box or by Email. Triggers are system-wide and will normally be triggered regardless of which user causes the event to occur.
As an alternative to sending messages to users with the Message Box system, a Trigger can create a Marketing Event that will be appended to a Marketing record's event list. Such triggers can also be sent by Email. Such Marketing Event Triggers can only be sent direct for a trigger associated with a Marketing record, or indirectly for an Customer event or Supplier event where the Customer or Supplier is linked to a Marketing record. It these conditions do not apply, no event will be created. See Target Users below for details of the syntax employed. For information on Marketing events see the Marketing Data Maintenance window help.
As an alternative to sending messages to explicit Email addresses such as email@example.com, where appropriate you can send to a customer or supplier address or contact email address. This is known as Indirect Email Addressing. See Target Emails below for details of the syntax employed.
Generic triggers are predefined in the system and when the maintenance window opens will be listed in the upper left list. You can add, using drag-and-drop, as many triggers as you like each of which can be tailored to your exact needs by adding a Condition. These conditions must be entered as logical Omnis Studio calculations that resolve to a non-zero or logically true value at runtime for the trigger to be instigated. No Condition will result in that generic event always being triggered. The message the trigger sends can be customised for each trigger and both the message and description can hold square-bracket Omnis Studio calculations that are evaluated at runtime. A default message is provided when you add trigger.
Once you have set up your triggers, they will be operational pretty much immediately. In normal data processing the trigger system operates internally as follows:
In all trigger circumstances, when the trigger is encountered, condition, description and message text evaluated occur together at a particular point in data processing with the global file data memory in a particular state. It is therefore important that only fields from files that can be assured to be in memory in their current state are used. For example, there is no point is using Supplier (SUPFILE) fields in a trigger for Customer credit because that file slot will be populated with data from any supplier, depending on previous user activity. If in the condition calculation, it would cause the trigger to be highly unpredictable.
As much as possible, the trigger point is placed such that expected history data to the event is available. So, for example, in part status triggers, the parts (PTMFILE) and inventory history (STHFILE) files are available. However, this is not the case if you have switched off the recording of inventory history, for some reason. Common sense needs to be used and in general only use fields from files that are illustrated already in the default message text data you will see when adding a new trigger.
In all cases global memory fields are available (the MEMORY file) and the company details file (MCDFILE), plus # variables. The following may be useful:
A special 2 decimal place number variable used in many triggers to hold the quantity processed (see default message texts as examples).
Special 3 decimal place number variables used in many triggers to hold the quantity processed (see default message texts as examples. Note, if not shown in the examples they will not contain useful values.).
A special text field that contains a list of line item data processed (see default message texts as examples, e.g. SO Dispatch or Customer Invoice).
Your company name as seen on reports
The processing user's id. This is useful if you want to restrict triggers to particular users. For example the condition statement m_UserId<>'SYS' would cause the trigger to operate unless the operation was instigated by the 'SYS' user.
The systems currency unit
The system currency text
WARNING: We do NOT recommend that you use oCustom1 custom functions in triggers unless they are extremely simple and never change the state of the Current Record Buffer.
System Triggers Available
Lists the available triggers. Drag those you want to add to the Operational Triggers list.
Lists the operational triggers. Drag from the Trigger list to add. Click to select and modify details. Use Delete key to remove.
The system code for the trigger type.
The description of the trigger. The description will be used as the resulting message heading. Can contain square bracket notation.
Enter a limiting logical condition (non-zero result) as a Studio calculation that will limit the triggers operation. Carriage returns characters and not permitted.
NOTE: Some triggers need to be controlled in their operation otherwise they will happen too often and their business significance will be lost. For example, customer credit limit being exceeded without a condition will send a message every time a transaction takes place when the account exceeds the credit limit. By adding the condition CUSOINV-CUSCRLT<=m_TriggerQty21 the message will only be sent on the occasion of the account going over the credit limit.
A comma separated list of users that will receive the triggered message. These must be system users's login IDs.
NOTE: As an alternative to a list of system users, you can specify the automatic creation of a Marketing Event. This is only useful where the trigger is associated with a Marketing record or a Customer or Supplier that is linked to a Marketing record. If such conditions apply, a Marketing Event will be generated. To effect this you need to enter the following syntax:
where CUS can be SUP or DEA to indicate whether it assiciated with a Customer, Supplier or Marketing event, TYP = the Event Type, REF = the Event Reference, and "Boss" can be any text that is used to identify the contact on the description contact field. The serach is case-sensitive and finds the last contact entered containing the text somewhere in the description. If the final entry is left blank, the default contact on the default address will be used.
A comma separated list of email addresses that will receive the triggered message.
NOTE: As an alternative to a list of explicit Email Addresses (such as firstname.lastname@example.org), you can specify a list of address or contact ID fields from which to derive an email address from the address or contact database. This is only useful where the trigger is associated with an address or contact record. You can list in priority order a number of fields, the first of which that relates to a valid email address will be used. To effect this you need to enter the following syntax:
The above example would be useful for a trigger on dispatch such as SODispatch. EMAIL= must start the entry followed by a list of entries. The fields, separated by a vertical bar character, can be any one of the following appropriate to the trigger circumstances: INVDADC, INVIADC, SOHDADC, SOHIADC, JOBDADC, JOBIADC, POHADC, PUHADC for contacts, and INVCAD, INVINVA, SOHCADS, SOHINVA, JOBCADS, JOBINVA, POHCADS, PUHCADS, CUSDADR, SUPDADR and DEADADR for addresses (In the case of CUSDADR, SUPDADR or DEADADR the default contact email is used, if valid, otherwise the default address for the customer, supplier or marketing record is used, if valid.). See also the note below. The final field on the list can be an absolute address, which will be used if none of the foregoing have valid email addresses. Finally, the EMAIL= syntax can form the first entry in a list of email addresses, so in the above dispatch trigger example, an email is sent to the Dispatch contact email, if valid, or the Dispatch address email, if valid, or email@example.com, if valid. In addition, one email is always sent to firstname.lastname@example.org
NOTE:For indirect address fields (not contacts) you can also append a contact description search string so that the contact with the text contained it its description will be used. The search text is appended with a colon. For example, CUSDADR:Boss will locate the last contact on any address for the customer that has been entered with "Boss" somewhere in the description. If none is found the default contact is used.
The message body text that the trigger will send. Can contain square bracket notation.
Click to test whether the message interprets correctly.
Click to test the trigger without conditions. You can then check the results.
Click to export the Operational Triggers for transfer to another datafile or for backup purposes. You will be prompted for a file name and destination.
Click to import the Operational Triggers exported previously. If you already have some Triggers you will be given the option of appending the imported triggers to the existing ones. You will be prompted for a file.
WARNING: Check that Users and Email Addresses are correct for any imported triggers.
To revert any changes to the previously saved version.
To save the changes you have made to the data file.
WARNING: Take care when using target emails as the destination. If they are used, all system users must have working email capabilities within the program. I.E. they must be able to send a report to the Email destination without error. If the Email send fails, the trigger message is lost.
|See also: -|
Compiled in Program Version 3.10. Help data last modified 5 NOV 2006 22:38. Class wTriggerMaint last modified 11 JAN 2012 04:15:33.
Reference Contents > Manager Controls > Workflow Trigger Alert Maintenance