Timezone information is not recorded for absences. Instead, this solution attempts to derive the user’s timezone based on the following precedence:
- The value of the ‘Client Timezone’ profile option at the User level. If enabled, this value can be set by each user on the standard User Preferences page.
- The timezone of the location on the person’s primary assignment.
- The value of the ‘Client Timezone’ profile option at the Site level.
The user’s timezone can also be set in the Fast Formula by setting the ‘Override_Timezone’ Formula Output. When set, this takes precedence over all three of the previous conditions.
The following formula extract sets the timezone to ‘Europe/London’ for all users.
/* +-------------------< SECTION 3: OTHER DEFAULTS >-------------------------
+
It is good practice to define default values for the Formula Outputs and
other variables that are used in this formula. This helps to guard
against
empty outputs being returned and keeps the formula tidy.
*/
...
Override_Timezone = 'Europe/London'
...
/* +-------------------< SECTION 5: RETURN OUTPUTS >-------------------------
+
This section returns the Outputs. The Outputs that are not used by
default are commented out. If you wish to use any of these you should
uncomment them and set their values further up.
*/
RETURN Send, From_Email, Subject, Free_Busy, Tentative, Privacy, Priority
,Default_Start_Time, Default_End_Time, Open_Ended_Days
,Override_Timezone
‘Europe/London’ is GMT without daylight saving and GMT+1 with daylight saving. For a list of timezone names that you can use, refer to the ‘TZ’ column in the following article:
List of tz database time zones
If you wish to use the Fast Formula to set the Override_Timezone but your users are based in multiple timezones, you will need to use conditions in the Fast Formula to set the timezone accordingly.
If the Override_Timezone is not specified in the Fast Formula and could not be determined using any of the 3 criteria described above, the calendar invite will send the absence as ‘Floating Time’, i.e., without any timezone information.
Not all calendars fully support the ‘Floating Time’ iCalendar specification, which results in varied behavior across different clients. Notably, at the time of writing, Outlook 2007 and Outlook 2010 instead convert ‘Floating Time’ appointments into the user’s local timezone at the time the appointment is accepted rather than the expected timezone at the date of the appointment. This can result in the scheduled absence being up to one hour incorrect.
Switch off OLM Delivery Methods
By default, all enrollments for all classes will send out a calendar invite. You may wish to suppress this functionality for classes of particular delivery methods. For example, eLearning is often set up as an open-ended class. If a calendar invite is sent for this class, it will block the learner’s calendar for all time.
Generally, classes that are associated with Delivery Methods of type ‘asynchronous’ should have this functionality disabled.
To disable the functionality, you are required to modify the Learning Fast Formula. As recommended above, you should take a copy of the default formulas, XXAS_OUT_ENR_EVENT (for internal learners) and XXAS_OUT_CUST_ENR_EVENT (for external learners), and modify the copy.
Once you have copied the Fast Formula, follow the steps below:
- Navigate to Write Formula screen
- Query back the formula name and press the ‘Edit button’
- In the formula text displayed, find the following section:
/* +-------------------< SECTION 4: MAIN BODY >------------------------------
+
This is usually the only section you may wish to modify. This contains
logic that adjusts the Outputs according to certain conditions.
For example, the below prevents invites from being sent for e-Learning
and CD-ROM delivery modes.
*/
/* Send invites depending on the Delivery Mode. You can update this
section to include the delivery modes you do not wish to send invites
for. */
if Delivery_Mode = 'eLearning' or
Delivery_Mode = 'CD-ROM'
then
(Send = 'No')
- Modify the delivery methods marked ‘eLearning’ and ‘CD-ROM’ to match the names of the delivery methods that you wish to suppress.
- If you have more than two delivery methods, then simply add additional clauses, e.g., the above clause could change to:
if Delivery_Mode = 'eLearning' or
Delivery_Mode = 'CD-ROM' or
Delivery_Mode = 'Book'
then
(Send = 'No')
- Press the ‘Verify’ button, close the window, and then press ‘Save’. Note: Ensure you press the ‘Save’ button after verifying the formula; it is easy to forget to do this and lose your change!
- Your formula has been modified and no calendar invites will be sent for any enrollments made for classes attached to those delivery methods.
- If you are going to send invites to external learners, remember to change XXAS_OUT_CUST_ENR_EVENT in the same way.
You must type the name of the Delivery Method exactly, including Upper/Lower case and punctuation such as hyphens. Failure to do so will mean those delivery methods will not suppress calendar invites.
Switch off Resource Types
You can control which types of resources have calendar invites sent to through via the formula XXAS_OUT_RESOURCE_EVENT. Examples of Resource Types are Trainers, Venues, Rooms, Books, Equipment; anything needed to run a training class.
You will probably not want all resource types to receive a calendar invite. The mechanism to suppress invites is similar to that described above for Delivery Methods.
In the seeded formula, XXAS_OUT_RESOURCE_EVENT, you will see the following code:
If Resource_Type = 'Book' Or
Resource_Type = 'Equipment'
20
Then
(Send = 'No')
In this example, if a resource is found against the class with a resource type of ‘Book’ or ‘Equipment’, then no calendar invite will be sent. You can add your own resource types to this list; use the meaning from the lookup type ‘RESOURCE_TYPE’.
Remember to take a copy of the seeded formula and modify your copy. If you change the seeded formula, your changes could be overwritten the next time a patch is applied.
Personalize Calendar Invites
The default calendar invites can be configured to match your requirements through the same Fast Formula as mentioned above.
Several Inputs are passed into each formula that enables you to define dynamic calendar invites containing data such as Absence Type, Class Name, and so on, as well as defining your own message text. This section outlines how you achieve this.
Configuring Fast Formula in this way is not something intended for Administrators. However, it should be possible for a functional administrator to configure without the need for a technical developer. More advanced features may require custom PL/SQL to be written which would require technical expertise.
Embed Resource information in Calendar Invites for Learners
If you store information about Class Resources, such as Venues & Training Instructors, then you can embed information about them within the calendar invites that get sent to learners (both internal and external).
Two new formula functions are delivered which will retrieve information about any resource type that has been associated with the class or session. These formula functions are embedded within the updated version of XXAS_OUT_ENR_EVENT and within the new formula XXAS_OUT_CUST_ENR_EVENT.
These formula functions populate local formula variables with information about the resource which you can then use in the message content of your calendar invite.
xxas_get_internal_trainer
Internal trainers are usually employees or contractors that you already store in your Oracle HR system and who can perform a training role. They differ from other resources in that their personal details, such as name and email address, are stored on the regular HR tables, like PER_ALL_PEOPLE_F.
This formula function retrieves the following information for the internal trainer:
- First Name
- Last Name
- Email Address
- Trainer_ID
The Trainer_ID is the primary key of the person record, i.e., PER_ALL_PEOPLE_F.PERSON_ID. It is also held on the Resource definition, in the table OTA_SUPPLIABLE_RESOURCES.
If you require further information to be retrieved about the trainer, you can use this return variable to pass into your own formula functions which can get that information back. The formula function is called as follows:
Result = xxas_get_internal_trainer(Event_id, First_Name, Last_Name, Trainer_Email, Trainer_Id)
The Event_ID is an input variable to the Formula; the other variables are used to capture return information.
The formula function returns 1 if an internal trainer is found and 0 if no internal trainer exists for the class.
To see further information about how to use this formula, please refer to the content of the formulas XXAS_OUT_ENR_EVENT and XXAS_OUT_CUST_ENR_EVENT.
The function assumes that you only have one internal trainer per class. In rare cases, you may define multiple trainers for a single class, each having multiple roles. If you have this scenario, you will need to create your own formula function and call it multiple times for each trainer role. Please contact Applaud Support if you need assistance in performing this configuration.
xxas_get_resource_booking
Other resources, including external trainers, are modeled flexibly in Oracle Learning Management using a key flexfield. Every Resource has to have a ‘Resource Type’ (defined by the lookup RESOURCE_TYPE).
Examples of resource types are Trainer, Venue, Room, Equipment, Book, Software.
If you use resources extensively, it is unlikely that you will want every single resource listed in a calendar invite. However, you might wish to post details about the Room the training is being held in or the Venue address. Also, if you hold details about external trainers, you will need to use this formula function (as opposed to xxas_get_internal_trainer) to get their details into the calendar invite.
This formula function retrieves the following information for the internal trainer:
- Resource Name (this is the full concatenated string held in the keyflex table)
- Resource Address
- Supplied_resource_id
If there is other resource information you need to retrieve, you can use the supplied_resource_id in your own formula function; this is the primary key for the table OTA_SUPPLIABLE_RESOURCES which holds all resource information.
The formula function is called as follows:
Result = xxas_get_resource_booking(Event_id, Resource_Type, Resource_Name, Resource_Address, Supplied_Resource_Id)
The Event_ID is an input variable to the Formula and identifies the class or session. The Resource Type must be set by you, for example, ‘Venue’ or ‘Room’. The value in this variable should match the equivalent lookup meaning for the Lookup Type ‘RESOURCE_TYPE’.
The formula function will then attempt to find if a resource of that type has been associated with that class or session. It will return 1 if found, a 0 if not.
You can then embed the resulting variables, like Resource Name, in your calendar invite. To see further information about how to use this formula, please refer to the new version of XXAS_OUT_ENR_EVENT and the new formula XXAS_OUT_CUST_ENR_EVENT.
If you have multiple resources of the same type against a class or session, then this formula function will only return one single result. You will be required to create your own formula function to return multiple results. Please contact Applaud Support if you need advice on how to achieve this.
Setting Resources against Classes and Sessions
If the calendar invite is being generated for a session, then the formula function will firstly look for a resource held against the session and, if not found, look for a resource held against the class. This allows you to set resources at the class level if they are common across all sessions, e.g., a particular Room booking or trainer.
However, if you follow this approach, we recommend you do not ‘mix and match’. If you set a trainer, say, at class level and also set trainers at the session level, then the results will be undefined. Set all resources of the same type at either class level or session level, not both. So, for example, you could define a ‘Room’ against the class (indicating all sessions will be held in the same room) and then define different trainers at session level (indicating that different trainers take different sessions).
Absence Formula Inputs
This table describes each Input available to the Absence formula:
Parameter Name | Description | Example Value |
---|---|---|
Component | Set to C for Calendar | C |
Change_Type | Determines if the event is a new event, an update to an existing event, or a cancellation (delete) | New, Update, Cancel |
Absence_Id | The Primary Key ID for the absence | 1050340 |
Absence_Type | The text form of the Absence Type (case sensitive) | Sickness |
Absence_Reason | The text form of the Absence Reason | Cold or Flu |
Date_Notification | From the absence field ‘Date Notified’ (not used in default invite) | 2008/02/01 00:00:00 |
Date_Projected_Start | The projected start date of the absence | 2009/03/01 00:00:00 |
Time_Projected_Start | The projected start time of the absence | 09:00 |
Date_Projected_End | The projected end date of the absence | 2009/03/27 00:00:00 |
Time_Projected_End | The projected end time of the absence | 17:00 |
Date_Start | The actual start date of the absence | 2009/03/01 00:00:00 |
Time_Start | The actual start time of the absence | 09:00 |
Date_End | The actual end date of the absence | 2009/03/27 00:00:00 |
Time_End | The actual end time of the absence | 17:00 |
Absence_Days | The absence duration in days (not set if Absence Hours is set) | 2 |
Absence_Hours | The absence duration in hours (not set if Absence Days is set) | 16 |
The following rows are only set on Update & Cancel events and allow you to work with details of the absence before the update or cancellation actions take place. For example, you might want to include the comment ‘Annual leave changed from 01-MAR-2009 to 10-MAR-2009’ in the body of the calendar invite.
Parameter Name | Description | Example Value |
---|---|---|
Old_Absence_Reason | As above for record pre-update or pre-delete | As above |
Old_Date_Notification | As above for record pre-update or pre-delete | As above |
Old_Date_Projected_Start | As above for record pre-update or pre-delete | As above |
Old_Time_Projected_Start | As above for record pre-update or pre-delete | As above |
Old_Date_Projected_End | As above for record pre-update or pre-delete | As above |
Old_Time_Projected_End | As above for record pre-update or pre-delete | As above |
Old_Date_Start | As above for record pre-update or pre-delete | As above |
Old_Time_Start | As above for record pre-update or pre-delete | As above |
Old_Date_End | As above for record pre-update or pre-delete | As above |
Old_Time_End | As above for record pre-update or pre-delete | As above |
Old_Absence_Days | As above for record pre-update or pre-delete | As above |
Old_Absence_Hours | As above for record pre-update or pre-delete | As above |
Learning Management Formula Inputs
This table describes each Input available to the Learning Management formula: XXAS_OUT_ENR_EVENT (for internal learners), XXAS_OUT_CUST_ENR_EVENT (for external learners), XXAS_OUT_RESOURCE_EVENT (for resource bookings). Not all of these input variables are available to each formula. Further documentation is available within the Formula text.
Parameter Name | Description | Example Value |
---|---|---|
Component | Set to C for Calendar | C |
Change_Type | Determines if the event is a new event, an update to an existing event or a cancellation | New, Update, Cancel |
Class_or_Session | If the calendar invite is for a Class, this is set to ‘C’, if it is for a Session, this is set to ‘S’. This will always be ‘S’ if the class has sessions. | C, S |
Class_Name | The name of the Class | Basic First Aid 01-MAR-2009 |
Session_Name | The name of the Session | Introductory Workshop |
Course_Name | The name of the Course | Basic First Aid |
Training_Center | The text name of the Training Center | Brackwood House |
Training_Center_Id | The Primary Key Id of the Training Center | 10345 |
Location_Name | The text name of the Location | Wingwood |
Location_Id | The Primary Key Id of the Location | 943645 |
Booking_Id | The Primary Key Id of the Booking being processed (from OTA_DELEGATE_BOOKINGS) | 1365465 |
Event_Id | The Primary Key Id of the Class or Session being processed (from OTA_EVENTS) | 3245235 |
Start_Datetime | The Start Date and Time of the event | 2009/03/01 09:00:00 |
End_Datetime | The End Date and Time of the event | 2009/03/22 17:00:00 |
Customer_Id | The Primary Key Id of the Customer (external learners only) | 2323 |
Booking_Status_Type | The text form of the Booking Status | Enrolled, Placed |
Delivery_Mode | The text form of the Delivery Mode | Instructor Led Training, eLearning |
Supplied_Resource_ID | The Primary Key ID of the Resource being booked (from OTA_SUPPLIABLE_RESOURCES) | 543543 |
Resource | Name The name of the resource, taken from the concatenated keyflexfield | Golden Gate Room.San Francisco |
Supplier_Reference | Details about a resource. Also used to hold a contact email address of a resource. | VEN-01, contact@applaudsolutions.com |
Resource_type | The type of resource, taken from the lookup RESOURCE_TYPE | Venue, Book |
Internal_Trainer_First_Name | Self explanatory. Taken from PER_ALL_PEOPLE_F | Ned |
Internal_Trainer_Last_Name | As above | Stark |
Internal_Trainer_Email | As above | Ned.stark@example.org |
Resource_contact | Taken from the resource booking. Can be used to hold the contact email address of the resource | roomadmin@applaudsolutions.com |
Trainer_Role | For Trainers only: The role they are taking on the class. Stored against the resource booking | Observer; Primary Trainer |
Trainer_ID | The primary key identifying internal trainers. Joins to PER_ALL_PEOPLE_F.PERSON_ID | 3243232 |
Booking_Status | The status of the Resource Booking | Planned, Confirmed |
Customer_ID | The id of the Customer Organization the external learner belongs to | 453543 |
Contact_ID | A person can be specified as a contact for any enrollment (usually someone different to the learner, e.g., a Personal Administrator). This ID is the primary key to that person. | 453534 |
Delegate_Contact_ID | The ID of the external learner. Not used for internal learners. | 543453453 |
Use of Database Items
The formulas XXAS_OUT_ENR_EVENT and XXAS_OUT_ABS_EVENT include the Assignment Id and Business Group Id context, which allows you to include many of the common Fast Formula Database Items, e.g., Organization, Job, Person Name etc.
The formulas XXAS_OUT_CUST_ENR_EVENT and XXAS_OUT_RESOURCE_EVENT do not have a context of Assignment ID but do have a context of Business Group ID. You will be limited to database items that work with this single context.
For more information on Database Items, please refer to the Oracle Fast Formula User Guide.
Use of Formula Functions
Many seeded and customer-defined formula functions can be used, which offer maximum flexibility in configuring your calendar invites. For more details on how to make use of Formula Functions, please refer to the Oracle Fast Formula User Guide.
To see examples, please review the two formula functions that are shipped with this solution: xxas_get_internal_trainer and xxas_get_resource_booking.
Absence Formula Outputs
The outputs of the formula are used to construct the calendar invite. The following table describes the Formula Outputs available to the absence formula and indicates those that are mandatory (i.e., they must return a value).
Output Name | Mandatory | Description | Example Value |
---|---|---|---|
Send | Yes | Determines whether to send the invite or not. | Yes, No |
From_Email | No | The sender of the calendar invites, typically a ‘noreply@’ email address. If this is not specified, the sender is the same as the recipient. | noreply@applaudsolutions.com |
Subject | Yes | The Subject of the calendar invite | Updated: Annual Leave |
Free_Busy | Yes | Determines whether the calendar event shows as Free or Busy when accepted. Note that this value is not supported by all email clients. | Free, Busy |
Tentative | Yes | Determines whether the calendar event shows as Tentative when accepted. Note that this value is not supported by all email clients and can be overridden by the user ‘accepting’ the invite rather than marking it as tentative. | Yes, No |
Privacy | Yes | Determines whether the calendar invite is shown as Public (details can be viewed by others), Private (details cannot be viewed) or Confidential (transparent). Note that this value is not supported by all email clients and can be overridden by the user. | Public, Private, Confidential |
Priority | Yes | Set to a value from 0-9. 0 is an unassigned priority, 1 is the highest priority and 9 is the lowest priority. Note that this value is not supported by all email clients. | 0,1,2,3 etc |
Default_Start_Time | No | For absences where the time is unspecified (eg, days-based absences), this specifies the Absence Start Time. If this is not specified, midnight (00:00) is used. | 09:00 |
Default_End_Time | No | For absences where the time is unspecified (eg, days-based absences), this specifies the Absence End Time. If this is not specified, 1 minute to midnight (23:59) is used. | 17:30 |
Open_Ended_Days | No | If an absence is open-ended, this specifies how many days are blocked out in the user’s calendar. If unspecified, this defaults to 366 | 5 |
Location | No | Contents of this field appear in the Location value of the Calendar Invite | London, UK |
Override_Timezone | No | Sets the user’s timezone. For more information, refer to the topic Configuring Timezone Support for Absences. | Europe/London |
HTML_Body | No | The body text of the calendar invite. The HTML_Body output can be written in Plain Text or, to improve the look of each calendar invite, in HTML. This gives you up to 255 characters of HTML text. For up to 4000 characters, use the alternative Outputs detailed below. | Absence Reason: Paid Leave |
HTML_Message_App | No | Only relevant when HTML_Message1 and optionally HTML_Message2 are also specified. These Outputs offer an alternative to the HTML_Body output and enable up to 4000 characters of HTML text (2000 for HTML_Message1 and an additional 2000 for HTML_Message2). If these are used, HTML_Body should not be returned as an Output. Set this to the Application Short Name of the Application that owns the FND Message specified by HTML_Message1. If HTML_Message2 is also specified, this is used to determine the owning Application of that message as well. | XXAS |
XXAS HTML_Message1 | No | Specifies the name of a Message defined in the Application Message Dictionary (Application Developer > Application > Messages). If specified, HTML_Message_App must also be specified and HTML_Body should not be used. The message can contain HTML markup and up to 10 message tokens. Where used, message tokens should be specified using the HTML_Message1_TokenN_Name and HTML_Message1_TokenN_Value Outputs (where N is a number between 1 and 10). | XXAS_OUT_ABS_FND_MSG1 |
HTML_Message1_Token1_Name | No | When HTML_Message1 is used and contains tokens, this specifies the name of one of the tokens. For example, if the message contains an &ABSENCE_TYPE token this should be set to ABSENCE_TYPE (without the ampersand). The tokens do not need to be specified in any particular order, i.e., this does not need to be the first token that appears in the message. | ABSENCE_TYPE |
HTML_Message1_Token1_Value | No | This specifies the value of the message token specified by HTML_Message1_Token1_Name. For example, if HTML_Message1_Token1_Name is set to &ABSENCE_TYPE this could be set to ‘Annual leave’. If HTML_Message1_Token1_Name is specified this must also be specified. | Annual leave |
HTML_Message1_TokenN_Name | No | Up to 10 message tokens can be specified for HTML_Message1. Replace N with a number between 1 and 10. Refer to HTML_Message1_Token1_Name for details on setting a token name. | ABSENCE_TYPE |
HTML_Message1_TokenN_Value | No | Replace N with a number between 1 and 10. This should be set to the token value of the equivalent token. Refer to HTML_Message1_Token1_Value for details on setting a token value. | Annual leave |
HTML_Message2 | No | Specifies the name of a Message defined in the Application Message Dictionary (Application Developer > Application > Messages). If specified, HTML_Message_App and HTML_Message1 must also be specified and HTML_Body should not be used. When this is specified, the contents of HTML_Message1 and HTML_Message2 will be concatenated together. Message tokens should be specified using the HTML_Message2_TokenN_Name and HTML_Message2_TokenN_Value Outputs (where N is a number between 1 and 10). | XXAS_OUT_ABS_FND_MSG2 |
HTML_Message2_TokenN_Name | No | Up to 10 message tokens can be also be specified for HTML_Message2. Replace N with a number between 1 and 10. Refer to HTML_Message1_Token1_Name for details on setting a token name. | ABSENCE_TYPE |
HTML_Message2_TokenN_Value | No | Replace N with a number between 1 and 10. This should be set to the token value of the equivalent token. Refer to HTML_Message1_Token1_Value for details on setting a token value. | Annual leave |
Learning Management Formula Outputs
The outputs of the formula are used to construct the calendar invite. The following table describes the Formula Outputs available to the learning management formula and indicates those that are mandatory (i.e., they must return a value):
ut Name | Mandatory | Description | Example Value |
---|---|---|---|
Send | Yes | Determines whether to send the invite or not. | Yes, No |
From_Email | No | The sender of the calendar invites, typically a ‘noreply@’ email address. If this is not specified, the sender is the same as the recipient. | noreply@applaudsolutions.com |
Subject | Yes | The Subject of the calendar invite | Training: First Aid |
Free_Busy | Yes | Determines whether the calendar event shows as Free or Busy when accepted. Note that this value is not supported by all email clients. | Free, Busy |
Tentative | Yes | Determines whether the calendar event shows as Tentative when accepted. Note that this value is not supported by all email clients and can be overridden by the user ‘accepting’ the invite rather than marking it as tentative. | Yes, No |
Privacy | Yes | Determines whether the calendar invite is shown as Public (details can be viewed by others), Private (details cannot be viewed), or Confidential (transparent). Note that this value is not supported by all email clients and can be overridden by the user. | Public, Private, Confidential |
Priority | Yes | Set to a value from 0-9. 0 is an unassigned priority, 1 is the highest priority and 9 is the lowest priority. Note that this value is not supported by all email clients. | 0,1,2,3 etc |
Location | No | Contents of this field appear in the Location value of the Calendar Invite | London, UK |
RSVP | No | If set to ‘Y’, declines and acceptances are sent back to the class organizer. See later section for more details on RSVP | 'Y' or 'N' |
HTML_Body | No | The body text of the calendar invite. The HTML_Body output can be written in Plain Text or, to improve the look of each calendar invite, in HTML. This gives you up to 255 characters of HTML text. For up to 4000 characters, use the alternative Outputs detailed below. | <html>Enrollment Status: <b>Waitlisted</b> </html> |
HTML_Message_App | No | Only relevant when HTML_Message1 and optionally HTML_Message2 are also specified. These Outputs offer an alternative to the HTML_Body output and enable up to 4000 characters of HTML text (2000 for HTML_Message1 and an additional 2000 for HTML_Message2). If these are used, HTML_Body should not be returned as an Output. Set this to the Application Short Name of the Application that owns the FND Message specified by HTML_Message1. If HTML_Message2 is also specified, this is used to determine the owning Application of that message as well. | XXAS |
XXAS HTML_Message1 | No | Specifies the name of a Message defined in the Application Message Dictionary (Application Developer > Application > Messages). If specified, HTML_Message_App must also be specified and HTML_Body should not be used. The message can contain HTML markup and up to 10 message tokens. Where used, message tokens should be specified using the HTML_Message1_TokenN_Name and HTML_Message1_TokenN_Value Outputs (where N is a number between 1 and 10). | XXAS_OUT_ABS_FND_MSG1 |
HTML_Message1_Token1_Name | No | When HTML_Message1 is used and contains tokens, this specifies the name of one of the tokens. For example, if the message contains an &ABSENCE_TYPE token this should be set to ABSENCE_TYPE (without the ampersand). The tokens do not need to be specified in any particular order, i.e., this does not need to be the first token that appears in the message. | CLASS_NAME |
HTML_Message1_Token1_Value | No | This specifies the value of the message token specified by HTML_Message1_Token1_Name. For example, if HTML_Message1_Token1_Name is set to &ABSENCE_TYPE this could be set to ‘Annual leave’. If HTML_Message1_Token1_Name is specified this must also be specified. | First Aid |
HTML_Message1_TokenN_Name | No | Up to 10 message tokens can be specified for HTML_Message1. Replace N with a number between 1 and 10. Refer to HTML_Message1_Token1_Name for details on setting a token name. | CLASS_NAME |
HTML_Message1_TokenN_Value | No | Replace N with a number between 1 and 10. This should be set to token value of the equivalent token. Refer to HTML_Message1_Token1_Value for details on setting a token value. | First Aid |
HTML_Message2 | No | Specifies the name of a Message defined in the Application Message Dictionary (Application Developer > Application > Messages). If specified, HTML_Message_App and HTML_Message1 must also be specified and HTML_Body should not be used. When this is specified, the contents of HTML_Message1 and HTML_Message2 will be concatenated together. Message tokens should be specified using the HTML_Message2_TokenN_Name and HTML_Message2_TokenN_Value Outputs (where N is a number between 1 and 10). | XXAS_OUT_ABS_FND_MSG2 |
HTML_Message2_TokenN_Name | No | Up to 10 message tokens can be also be specified for HTML_Message2. Replace N with a number between 1 and 10. Refer to HTML_Message1_Token1_Name for details on setting a token name. | CLASS_NAME |
HTML_Message2_TokenN_Value | No | Replace N with a number between 1 and 10. This should be set to the token value of the equivalent token. Refer to HTML_Message1_Token1_Value for details on setting a token value. | First Aid |
Calendar Invites for Absences
This section describes how calendar invites are sent out when Absences are created, updated or canceled.
Important: Calendar Invites will not be sent if the employee has no email address on either their Person or User record.
Creating an Absence
Calendar Invites are sent out when a new absence is:
- entered through the Professional Form
- entered through Self Service and then approved
The actual dates and times (or projected dates and times if the actuals are not defined) form the detail of the calendar invite and the absence type is used in the Subject (unless configured differently through the Absence Event Fast Formula). Timezone information is used when available.
By default, all absences booked will cause a calendar invite to be sent to the person to whom the absence relates. Certain absence types can be suppressed by using the Fast Formula, as described in the sections above.
Updating an Absence
By default, updates to an absence calendar invite will only be sent if there is a change to the date or time of the absence. Any other changes to the absence, e.g., to a flexfield value or to absence reason, will not cause any calendar update to be sent.
This can be changed using the Fast Formula. For example, if you hold pertinent information in a flexfield segment and you wish this value to i) appear in the calendar invite, ii) trigger an update to an existing calendar invite, then this can be configured through the Fast Formula. Please refer to the documentation within the Fast Formula itself for further instruction.
Canceling an Absence
A calendar cancellation is sent out once an absence is deleted, regardless of whether the absence is deleted through the professional form or through Self Service.
Calendar Invites for Oracle Learning Management
This section describes how calendar invites are sent out when enrollments are made, changed, or canceled and when classes or sessions are changed.
Note that calendar invites are sent out to applicants, employees, and contingent workers. Calendar invites are not sent out to external learners, i.e., customers.
Calendar Invites will not be sent if the applicant, employee, or contingent worker has no email address on either their Person or User record.
Enrollments
Calendar invites are sent out when enrollments are made for classes that have a delivery method that is enabled through the Enrollments Fast Formula.
New enrollments
New enrollment will cause a calendar invite to be sent to the learner being booked onto the class.
Class Dates & Times
The dates and times of the class will be used to create the start and end dates & times of the calendar booking.
The Location and Training Centre of the class determines the Location of the calendar invite. If both are set, then the Training Centre takes precedence but that can be changed through the Fast Formula if required.
Calendar invites are not sent out for classes without start or end dates, for example, Planned Classes.
Enrollment Statuses
Calendar invites are not sent out when the enrollment is created with a status of ‘Attended’ as the inference is the learner has already been in the class and will not require a calendar invite.
Calendar invites are sent out for enrollments created for any other enrollment status (note that enrollments cannot be created as ‘Cancelled’).
By default, the enrollment status forms the body of the calendar invite.
New enrollments for classes with sessions
Sessions are often used to break up classes that run non-continuously over a longer period of time. In these cases, learners are only sent calendar invites for the time they are spending on the class, i.e., those time slots defined by the sessions. If a class has sessions, then a separate calendar invite is sent out for each session, rather than one calendar invite for the class. So for example, suppose a class has the following Sessions:
Session Name | Stat Date | Start Time | End Time | Location |
---|---|---|---|---|
Introductory Session | 01-Mar-2009 | 09:00 | 17:00 | Woodham Center |
Basic Skills | 03-Mar-2009 | 09:30 | 16:30 | Woodham Center |
Lessons Learnt | 07-Mar-2009 | 09:00 | 12:00 | Barkwool College |
Evaluation | 10-Mar-2009 | 09:00 | 11:00 | Great Hall |
In the above example, 4 calendar invites would be sent out to each learner enrolled into the class rather than one calendar invite spanning 01-Mar-2009 through to 10-Mar-2009. Each calendar invite would have the date and times of the session rather than the class, together with the location of the session. Any date, time, or location information set at the class level is ignored.
Updates to enrollments
Change to enrollment status
If an enrollment status changes, e.g., from Waitlisted to Placed, then a new calendar invite is issued to the learner. The calendar invite will update the existing invite.
The exception is when enrollment is updated to ‘Attended’. In this case, the inference is the class is in the past and there is no need to issue a new calendar invitation.
Change to class
Learners can be moved onto another class by updating the class held against the enrollment. In this case, a calendar cancellation will be sent to remove the learner’s booking to go onto the original class. Then a new calendar invite will be issued for the new class.
Change to person
It is possible to update an enrollment to change the person the enrollment has been booked for, although this is not best practice and not recommended.
Nevertheless, the solution does support this operation. In the case of an enrollment being updated in this way, a calendar cancellation will be sent to the original person the enrollment was created for and a new calendar invite will be sent to the new person.
Resource changes
Changes to a resource held against a class or session will not send out calendar invites to learners. So, for example, if you changed the Room of a class (and the Room is held as a Resource), then this will not generate any calendar invites. You will need to make a change to the class or session to force out new invites. We recommend changing a field like an end time, saving, and then changing the end time back to what it was before. This will force new invites to be sent out; only one set will be sent with the latest information.
Other changes
Any other changes to enrollment will not cause any calendar invite to be sent out.
Mass updates to enrollments
If performing a mass update to enrollment, for example, updating a group of learners from waitlisted to place, then this action will send out calendar invites to all learners affected.
Enrollment cancellations or deletions
Updating an enrollment to be canceled will send out a calendar cancellation.
Deleting an enrollment will also send out a calendar cancellation.
Classes
When the date, time, or location details of a class change, calendar updates are sent out to all learners enrolled in that class.
Updating a class
If any of the following class details are changed then updated calendar invites are sent out to all learners enrolled in that class:
- Start Date
- Start Time
- End Date
- End Time
- Location
- Training Center
- Timezone
Updates are not sent out to learners who are enrolled with a Canceled or Attended enrollment status.
Canceling a class
If a class is canceled, then the learner’s enrollments should be canceled through the enrollments screen using mass update functionality. This will send out calendar cancellations to all enrolled learners.
If the class cancellation feature is used to automatically cancel all enrollments then this will not trigger calendar cancellations.
Classes with Sessions
If a class has sessions, then the sessions drive the calendar updates or cancellations. Updates to the class will not generate any calendar updates with one exception. If the timezone is changed in the class, then all sessions have their timezones changed too. This will force out new calendar invites for the sessions.
Sessions
When a session is updated or canceled, all learners enrolled in the parent class will be sent calendar updates or cancellations.
Updating a Session
If any of the following session details are changed then updated calendar invites are sent out to all learners enrolled in the parent class:
- Start Date
- Start Time
- End Time (session end dates are always the same as the start date and cannot be changed)
- Location
- Training Center
- Timezone
Updates are not sent out to learners who are enrolled in the parent class with a Canceled or Attended enrollment status.
Canceling a Session
If a session is canceled, then calendar cancellations are sent out to all learners enrolled in the parent class.
New Sessions created for classes with learners
If a new session is created for a class that already has enrollments, then calendar invites are not sent to the learners. Sessions should be created before enrollments are entered. If this is not possible, then you should create the session without a start or end time, save, then update the session with times. This will force calendar invites to be sent out to all learners enrolled in the parent class.
Customer Enrollments
In Oracle Learning Management, you can enroll ‘external learners’ into your training classes. This is typically done when your organization offers training to learners who work outside of your organization, such as many Public Sector organizations, or if you sell training to external customers.
To use this functionality in Oracle Learning Management, you must define your external learners as ‘Customers’, using the Customer screen. You can then enroll external learners in the standard Enrollments screen.
You can send Calendar Invites to your external learners if you have defined them as Customers using Oracle Learning Management. External Learners must have an email address defined for them before Calendar Invites can be sent.
Defining External Learners
You can access the Customers screen via the following navigation path: Learning Management Administrator: Customers: Customer
Customer Search Screen
A Customer can be defined as an ‘Organization’ or a ‘Person’.
External Learners have to be defined as a ‘Person’ to be enrolled in a class and thus to receive a Calendar Invite. Calendar Invites are not sent to Customer Organizations, even if that Customer Organization has a contact email address attached.
Searching for Customer with a Customer Type of Person
At the top of the screen is a drop-down list offering a choice of customer type. In this drop-down, there are two choices: ‘Organization’ and ‘Person’. Select a customer type of ‘Person’ to search for or to create a new customer of that type.
Create or update customer details
Click on the customer name at the bottom of the screen to add or update details about that customer.
View or add a customer’s email address
On this update screen, the person’s email address can be viewed or added. If the person does not have an email address, add one using the ‘Create’ button.
The email entered here will be the email that Calendar Events are sent to once that customer is enrolled in a class.
If the customer does not have an email address, a calendar invite will not be sent to them.
Customers can be given multiple email addresses. In this scenario, Calendar Invites are sent to the primary email address.
Configuring Calendar Invites for external learners
The Fast Formula XXAS_OUT_CUST_ENR_EVENT controls calendar invites being sent to external learners. The formula essentially replicates the behavior of the formula that controls calendar invites being sent to internal learners – XXAS_OUT_ENR_EVENT.
The main differences are:
- There is no assignment context for external learners (as customers do not have assignments). Therefore any regular database items that you may wish to use in XXAS_OUT_ENR_EVENT would fail to compile for customers.
- The input variables differ slightly: for external learners, you have access to the following input variables: Customer_Id, Contact_Id, Delegate_Contact_Id. These can be used if you wish to retrieve more information about the delegate and the customer organization they represent.
Keeping the external learner formula separate also allows you to easily define different message content for your calendar invites.
Other than these differences, the configuration options are the same as described for the regular formula XXAS_OUT_ENR_EVENT and invites are sent out based on the rules described in the above section on ‘Enrollments’.
If you have configured that formula to display your own messaging within the calendar invites, you will need to replicate that configuration if you wish your external learners to receive the same content.
If you wish to make changes to the default formula, you should take a copy of the Applaud formula, renaming it appropriately. If you do not do this, then all subsequent Applaud patches could overwrite your modifications to the seeded formula.
Resources
You can send Calendar Invites to contacts for resource bookings, such as administrators of Rooms & Venues or to Training Instructors themselves.
When a resource is booked onto a class or session an appropriate calendar invite is then sent to that resource if a contact email address is specified. This section explains how to configure this feature.
Scenarios
Before configuring this feature, it is worth spending a few moments considering the various scenarios where this feature could be useful.
The obvious scenario is that of booking training instructors onto classes or sessions. Sending calendar invites to trainers will allow you to send details of the class booking and have that information pushed into their calendar.
However, many other resources, particularly externally sourced ones like Rooms and Venues, will often have a contact person responsible for reserving that resource. There is currently no facility in Oracle Learning Management to add these contact points into a Workflow, meaning your administrators have to manually email Resource Contacts with details of resource bookings. By storing the email of the contact person against the resource, you can automate this communication by sending out a calendar invite containing this information.
Finally, some organizations set up resources for email clients like Outlook. Rooms, in particular, can be set up in this way so that employees can see Room Availability within their Outlook Calendar. Such resources will have an associated email address; by storing this email address in Oracle Learning Management you can use Calendar Invites to automate the room booking procedure. Please note that this feature does not perform any scheduling and cannot identify resource booking clashes.
XXAS_OUT_RESOURCE_EVENT
A Fast Formula called XXAS_OUT_RESOURCE_EVENT controls calendar invites being sent to resources. The formula copies much of the behavior of the formula that controls calendar invites being sent to internal learners – XXAS_OUT_ENR_EVENT - but has other features that are specific to resource bookings.
The main differences are:
- There is no assignment context for resources (as resources do not have assignments). You may not use regular database items in this formula; the formula will not compile if you attempt to do so.
- There are many more input variables to the formula, including Trainer Name, Trainer Role, Supplier Reference, Resource_Type, and so on. These can be used to embed Resource information into your calendar invite.
- The email address can be retrieved from a variety of sources. See a later subsection for more details.
As this formula is separate from the ones that control calendar invite content for learners, you may embed different text within them using this formula.
Other than the differences listed above, the configuration options are the same as described in the main implementation guide for the regular formula XXAS_OUT_ENR_EVENT. If you have configured that formula to display your own messages within the calendar invites, you will need to replicate that configuration if you wish your resource contacts to receive the exact same content.
If you wish to make changes to the default formula, you should take a copy of the Applaud formula, renaming it appropriately. If you do not do this, then all subsequent Applaud patches will overwrite your modifications to the seeded formula.
Setting email address for Resources
Oracle Learning Management does not provide a standard field to hold an email address for a Resource. Outlook Calendar Invites attempts to locate email addresses using the following rules:
- If the resource is an internal trainer, i.e., is held as a person in your Oracle HR system, then it will retrieve the email address from their person record or if exists, their associated User record.
- If the resource is not an internal trainer, then the solution will examine the field ‘Reference’ which is held against the Resource definition. Calendar invites will then be sent to any email address held in this field. Note: if you use the field for some other purpose, then the solution does not attempt to validate whether the field content is a valid email address or not; the calendar invite will just not be sent if the field content is invalid.
- If neither of the above criteria stands, the solution will look at the ‘Contact’ field held against the resource booking. Calendar Invites will be sent to any email address held in this field. Please note that taking this approach requires the most manual effort as the contact email address will need to be entered each time the resource is booked onto a class or session.
- If none of the above applies to your configuration of Oracle Learning Management, you can retrieve and set the email address to use in the Fast Formula XXAS_OUT_RESOURCE_EVENT. Retrieve the email address using your own Fast Formula Function and then use it to set the output variable OVERRIDE_TO_EMAIL. In this way, you could hold the email address in a flexfield, freeing up the ‘Supplier Reference’ field for other purposes.
Oracle Learning Management provides very flexible resource definitions; the downside being that you may be using different methods to store email addresses. Please contact Applaud Support for advice on how Calendar Invites can be made to work with your particular configuration of Resources.
Resource Bookings
Calendar invites are sent out when resource bookings are made for classes that have the resource type enabled in the Resource Fast Formula.
New Resource Bookings
A new resource booking will cause a calendar invite to be sent to the resource, providing the Resource Type is enabled and the resource has an email address specified.
The dates and times of the resource bookings will be used to create the start and end dates and times of the calendar booking.
Resource Booking Start and End Dates and Times are stored independently of the dates and times of the corresponding class or session. To create a resource booking, you must specify these dates and times again, even if they are the same as the parent class or session. Calendar invites for resources ignore dates and times on the parent.
Resource Bookings for Sessions
Resource Bookings can be made against a class or against a session. Calendar invites are sent out in both cases. If the resource booking is for the class, then the details in the calendar invite (such as the class name) will relate to that class. If the resource booking is for a session, then details in the calendar invite will relate to that session.
If you make a resource booking against a class that has sessions, then multiple calendar invites will be sent out to that resource; one for each session. The behavior is the same as when enrolling a learner into a class with sessions.
Updates to resource bookings
If any of the following resource booking details are changed then updated calendar invites are sent out to the resource contact:
- Start Date
- Start Time
- End Date
- End Time
- Timezone
- Booking Status
- Trainer Role (only applicable for resources of type ‘Trainer’
- Contact
If any of these items are changed on a resource booking, then an ‘update style’ calendar invite will be sent out.
It is possible to update the resource name against a resource booking. Due to a limitation in the Oracle Learning Management APIs, it is not possible to automatically send out a cancellation Calendar Invite to the ‘old’ Resource Contact and create a new calendar invite for the ‘new’ Resource Contact. We recommend you work around this restriction by always canceling the old resource booking and creating a brand new booking with the new Resource. This will have the desired effect.
Resource booking cancelations
Canceling a resource booking will send out a calendar cancellation to the Resource contact.
Updates to classes or sessions
If you update the date or time of the class or session, the corresponding dates and times of the associated resource bookings are not affected. Therefore, no calendar invites will be sent out to resources due to the date or time of the class or session changing (the same is not true for learners, who will receive updates).
If the date or time of a class or session has changed, you must manually update the date or time of the resource booking. This is standard Oracle Learning Management functionality and not a restriction in the Calendar Invites product.
RSVP
You have the option to enable RSVP support in all calendar invites sent out for training courses.
Learners sometimes decline calendar invitations, mistakenly thinking that this would be enough to ‘unenroll’ themselves from any class booking.
RSVP support enables the learners to send a response to the administrator when they decline.
With the RSVP feature turned ‘on’, any response the user sends will be received by the email address specified as the ‘sender’ of the Calendar Invite. If this response is sent to your training team, then ‘declines’ can be monitored and responded to.
Enabling RSVP
The RSVP feature is controlled by Fast Formula. The following formulas have RSVP support built-in:
- XXAS_OUT_ENR_EVENT
- XXAS_OUT_CUST_ENR_EVENT
- XXAS_OUT_RESOURCE_EVENT
In each formula, there is a return variable defined that is named ‘RSVP’.
The RSVP variable is set to ‘Y’ or ‘N’. The following line of formula code turns ‘on’ the RSVP feature:
RSVP = 'Y'
RSVP is enabled by default in the seeded fast formula. To turn off the feature, set the variable to ‘N’.
Points to consider
RSVP is a very useful feature for administrators who would like to track which learners are declining their calendar invites. However, you should be aware of the following points before deploying live:
- Administrators will get all responses made by all learners. This will include acceptances and tentative invites. This could result in a lot of email acceptances being sent to your training team. If your training team wishes to receive notice of calendar declines but does not want to see calendar acceptances, we recommend you look into placing a filter on these email accounts.
- Some email clients handle RSVPs in different ways. This feature has been tested on Microsoft Outlook and a variety of other calendar clients, such as iOS and Googlemail. If your email client of choice does not behave in an expected way, please get in touch with Applaud Support.
- If you specify a distribution list as the sender of calendar invites (as opposed to a ‘real’ email address), then you may see unexpected results in some email clients. We recommend setting the ‘sender’ of calendar invites as a specific email address rather than a distribution list.
Building new Integration Points
If you have access to Oracle technical expertise, you can extend the supplied solution to build your own integration points within Oracle HRMS or any other Oracle Application. A public API is supplied for you to embed in your own extensions enabling you to generate calendar invites for events that occur within iRecruitment, Performance Management, Salary Reviews, and more.
Architecture Overview
Generating a calendar invite is a three-step process:
-
Derive the contents of the calendar invite, including a unique key
The standard information required for a calendar invite is:
- Unique ID
- Start Date
- Start Time
- End Date
- End Time
- Subject
- To (email address of recipient)
- From (email address of the person sending the invite, can be the same as the recipient)
- Location (optional)
- Body Text (optional)
The Unique ID can be any alphanumeric string and must be unique enough to identify that particular event. The same Unique ID must be used if sending updates or cancellations for that event.
Your custom code must derive the above fields for the calendar event you wish to create. For example, you might use the date of an appraisal review and hardcode the Subject to be ‘Performance Review’.
Your custom call could be made in a variety of ways, maybe from a Workflow event, custom trigger, or some other processing hook point.
-
Call Public API
Once you have derived the above information, you need to make a call to the Public API XXAS_ICAL_PKG.LOG_EVENT. The definition of the API is given below and there is further documentation within the package header itself.
If you attempt to log invalid events (for example, an unrecognized free/busy value) the API will silently fail and will not raise an exception. Instead, it sets the p_error boolean out parameter and you can use fnd_message.get to retrieve the error message.
p_misc_content can be used to set additional VCALENDAR content, such as repeating patterns or additional recipients.
-
Concurrent Program
Once you have called the API, running the concurrent program will send all events logged since the last time the process was run. If you call log_event with multiple ‘update’ events for the same Unique ID, only the latest update will be emailed as a calendar invite – this prevents lots of out-of-date invites from being sent.
Public API Definition
The public API supplied appears in the package XXAS_ICAL_PKG has the following definition. Further information can be obtained within the package header documentation. Call this API to log an event on the XXAS_ICAL_EVENTS table. Events logged on the table will get sent the next time the concurrent program is run.
-- ---------------------------------------------------------------- *
-- Name : log_event
-- Purpose : Logs the given iCalendar event ready for send processing
--
-- * @param p_component iCalendar component, either g_CALENDAR or g_TODO
-- * @param p_uid_key User key that uniquely identifies the event
-- * @param p_change_type Set to g_NEW, g_UPDATE or g_CANCEL
-- * @param p_from_email Email Address of Sender
-- * @param p_proxy_email When Sent on Behalf Of, Email Address of Real
Sender
-- * @param p_to_email Email Address of Recipient
-- * @param p_subject Subject of the Email
-- * @param p_html_body Body of the Email in HTML
-- * @param p_date_start Start Date and Time of the Event
-- * @param p_end_start End Date and Time of the Event
-- * @param p_timezone Set to Null for Floating Time, or g_UTC
-- * @param p_duration VCALENDAR-formatted duration, sent instead of
p_end_date
-- * @param p_free_busy Set to g_FREE for Free, or g_BUSY for Busy
-- * @param p_location Location of the iCalendar event
-- * @param p_tentative Set to g_TENTATIVE or g_NOT_TENTATIVE
-- * @param p_privacy Set to g_PUBLIC, g_PRIVATE or g_CONFIDENTIAL
-- * @param p_priority Set to 0 for no priority, or 1-9 for highest to
lowest
-- * @param p_misc_content Space for other VCALENDAR-formatted content
lines
-- * @param p_error Set to true if an error ocurred; false otherwise
-- * @rep:scope public
-- * @rep:displayname Log Event
-- ----------------------------------------------------------------- *
PROCEDURE log_event
(p_component in varchar2
,p_uid_key in varchar2
,p_change_type in varchar2
,p_from_email in varchar2
,p_proxy_email in varchar2 DEFAULT NULL
,p_to_email in varchar2
,p_subject in varchar2
,p_html_body in varchar2 DEFAULT NULL
,p_date_start in date
,p_date_end in date DEFAULT NULL
,p_timezone in varchar2 DEFAULT NULL
,p_duration in varchar2 DEFAULT NULL
,p_free_busy in varchar2 DEFAULT NULL
,p_location in varchar2 DEFAULT NULL
,p_tentative in varchar2 DEFAULT NULL
,p_privacy in varchar2 DEFAULT NULL
,p_priority in number DEFAULT NULL
,p_misc_content in varchar2 DEFAULT NULL
,p_error out nocopy boolean);