The Messages branch of the navigator tree lists all available workflow messages for the current item type.

A message is what a notification activity sends to a role in a workflow process. A message can prompt a user for a reply or an action to take that determines what the next activity in the process should be. The recipient of a workflow message is called the performer.

Each message is associated with a particular item type. This allows the message to reference the item type's attributes for token replacement at runtime when the message is delivered.

When you define a message, you can specify that the message prompts a recipient for a special result response value that the Workflow Engine then uses to determine how to branch to the next eligible activity in the process. You can create a message with context-sensitive content by including message attribute tokens in the message subject and body that reference item type attributes. You can also use message attribute tokens to embed inline images in the message body. A message function lets you include a formatted table of message attributes or an action history table in the message body. You can also attach message attributes that represent entire documents or URLs to a notification message. In addition, you can create message attributes that generate a response section that is unique to the message. You can also embed an Oracle Application Framework region within the message body.

You can drag a message onto the Notifications branch to create a new notification activity that sends that message. You can also drag a message directly onto an existing notification activity to update the message that the activity sends.

Message Result

When you create a message for a notification activity, you should make note of whether the notification activity has a Result Type specified. If it does, then the message you create needs to prompt the notification recipient for a special response that is interpreted as the result of the notification activity. The Workflow Engine uses that result to determine how it should branch to the next eligible activity in the process.

To create a message that prompts for this special response, complete the Result tab in the message's property page. The information you enter creates a special 'Respond' message attribute for the message that has an internal name of RESULT. The RESULT message attribute has a data type of Lookup and must be set to the same lookup type as the notification activity's Result Type. This ensures that the performer of the notification can choose from a list of possible response values that matches the list of possible results that the notification activity is expecting. See: Send and Respond Message Attributes.

Send and Respond Message Attributes

Once you create a message, you can define as many message attributes as necessary for that message. Message attributes are listed beneath a message in the navigator tree.

The source (Send or Respond) of a message attribute determines how the message attribute is used. When you define a message attribute with a source of 'Send', you can embed the message attribute in the subject and/or body of the message for token substitution. In addition, you can attach the message attribute to the message when the notification is sent.

Each message attribute has a specific data type. The value of a 'Send' message attribute can be a constant or can be a value returned by an item type attribute of that same data type. To embed a message attribute in a message's subject or body for token substitution, specify the internal name of the message attribute using the format &MESGATTR within the subject or body text.

A message attribute defined with a source of 'Respond' constitutes the response section of a message. A 'Respond' message attribute provides instructions that prompts a recipient for a response. When you define a 'Respond' message attribute, you must specify the data type of the attribute. You can also provide an optional default value for the response. The default value can be a constant or a value returned from an item type attribute of the same data type.

You can define 'Respond' message attributes of type URL or form if you want the notification recipient to respond to the notification through the specified Web page or form. In this case that custom Web page or form must mark the notification as closed and include a call to the Workflow Engine CompleteActivity() API to inform the Workflow Engine when the notification response is complete. Also, you must not define any 'Respond' message attributes of other types. Any response values that are required must be entered in the specified Web page or form. See: CompleteActivity.

If you define 'Respond' message attributes of type URL or form, the Notification Details page will display only the URL response links or form response icons and will not display any other response fields. However, users will still be able to reassign or request more information for the notification as usual, if the notification is defined to allow those options.

See: Message Attributes.

Action History

A notification that is sent to an unexpanded recipient role can include an action history table that shows what actions users have performed on the notification to date. The action history table contains a row for each previous execution of the same notification activity node in a process, as well as a row for the initial submission of the process. For example, for a requisition approval notification activity that sends a certain notification to several approvers in turn, the action history table would contain a row for each approver to whom the notification was sent, as well as a row for the process owner. Additionally, if a notification is reassigned to another user in either delegate or transfer mode, or if one user requests more information about the notification and another user answers or transfers that request, the action history contains rows for those actions also. If Oracle Workflow cannot apply a vacation rule because the rule would reassign the notification to the process owner or the from role for the notification, then the action history contains a row showing that the reassignment was prevented and the rule was not applied.

• If the notification requires a response, then Oracle Workflow automatically includes the action history table in the notification.

• If the notification does not require a response, then Oracle Workflow only includes the action history table automatically if the notification has been reassigned at least once or if at least one recipient has requested more information about the notification. However, you can manually include the action history table by calling the special message function WF_NOTIFICATION(HISTORY) in the message body.

The formatting of the action history table depends on whether the notification contains an embedded Oracle Application Framework region.

• If the notification contains an Oracle Application Framework region, or if it contains only plain text and calls to the special WF_NOTIFICATION() message function, the table is formatted as an Oracle Application Framework region.

• If the notification does not contain any Oracle Application Framework regions, but does contain references to other types of message attributes, then the table is formatted in a standard Oracle Workflow format.

The standard action history table provided by Oracle Workflow includes the following columns:

• Num - A sequence number indicating the order in which the actions on this notification took place, beginning at one (1) for the initial submission of the process by the process owner.

• Action Date - The date that a user acted on the notification.

• Action - The action performed on the notification.

• From - The user who performed the action.

• To - The next user who must act on the notification as a result of this action. For example, the next approver, the user to whom the notification was reassigned, or the user from whom more information was requested.

• Details - An additional note from the user who performed the action. To allow a recipient to add a note for the action history table while responding, you must create a special 'Respond' message attribute with the internal name WF_NOTE.

  Define the message attribute with the following properties:

  • Internal Name - WF_NOTE

  • Display Name - Note

  • Description - Note

  • Type - Text

  • Source - Respond

  When the WF_NOTE attribute is defined with a source of 'Respond', it appears as part of the notification response section, and the recipient can enter a note there when responding to the notification. Oracle Workflow retrieves the note text stored in the WF_NOTE attribute and displays it in the action history table.

  If the responder did not enter a note, or if the WF_NOTE message attribute was not defined for the notification, then the Note column in the action history table is left blank.

  Oracle Workflow also lets users enter notes while reassigning a notification, requesting more information, or answering a request for more information. These notes are likewise displayed in the action history table.

  To allow the process owner to add a note for the action of submitting the process and sending the initial notification, you must define a special message attribute named #SUBMIT_COMMENTS. See: #SUBMIT_COMMENTS Attribute.

You can optionally create a custom action history table to replace the standard action history table, using the special message attribute named #HISTORY. Your custom action history table must be formatted as an Oracle Application Framework region, PL/SQL document, or PL/SQL CLOB document. See: #HISTORY Attribute, Embedding Oracle Application Framework Regions in Messages, and WF_NOTIFICATION() Message Function.

You can use the special message attribute named #RELATED_HISTORY to include the action history of one notification in another notification. See: #RELATED_HISTORY Attribute.

WF_NOTIFICATION() Message Function

In addition to message attribute tokens, you can also use a special message function called WF_NOTIFICATION() to add context-sensitive content to a message body. Depending on the parameters you provide, the WF_NOTIFICATION() function can produce either a table of message attributes or an action history table for the notification.

By default, the tables are created as Oracle Application Framework regions, unless the message body also includes any message attribute tokens that reference values other than Oracle Application Framework regions. In this case, the tables are created in a standard Oracle Workflow format. See: Embedding Oracle Application Framework Regions in Messages.

Message Attribute Table

To include a table of message attributes in a message body, call WF_NOTIFICATION() with the ATTRS option followed by the internal names of the message attributes, separated by commas. Use the following format:

WF_NOTIFICATION(ATTRS,<attribute1>,<attribute2>,<attribute3>,...)

The message attribute table contains a row for each message attribute listed in the WF_NOTIFICATION() call, showing the display name and the value for each attribute.

Action History Table

To include an action history table in a message body, call WF_NOTIFICATION() with the HISTORY option in the following format:

WF_NOTIFICATION(HISTORY)

The action history table contains the standard action history information provided by Oracle Workflow, unless you have defined the #HISTORY attribute for a message to use a custom action history region instead. See: Action History and #HISTORY Attribute.

#WF_REASSIGN_LOV Attribute

You can use a special message attribute with the internal name #WF_REASSIGN_LOV to specify the users to whom a message can be reassigned. Create a role whose members are all the users that you want to allow as possible new recipients when the notification is reassigned, and assign this role as the value for the #WF_REASSIGN_LOV attribute. Then, when the notification recipient attempts to reassign the notification, only the users that belong to that role will appear in the list of values for the Assignee fields in the Reassign Notifications page. See: To Reassign a Notification to Another User.

The #WF_REASSIGN_LOV attribute must be of type role and must have a source of Send. You can either specify a particular role as a constant value for the #WF_REASSIGN_LOV attribute, or specify an item type attribute as the value and include logic in your workflow process that dynamically sets that item type attribute to the role you want at runtime. If no existing role meets your needs, you can include logic in your process to create an ad hoc role at runtime and add the users you want to that role. See: CreateAdHocRole and AddUsersToAdHocRole.

#HIDE_REASSIGN Attribute

You can use a special message attribute with the internal name #HIDE_REASSIGN to hide the Reassign button in the Notification Details Web page. The response section in the Notification Details page includes the Reassign button by default. If you want to restrict users from reassigning a notification, you can add the #HIDE_REASSIGN attribute to control whether the Reassign button is displayed or hidden. See: To Reassign a Notification to Another User.

The #HIDE_REASSIGN attribute also controls whether a notification can be reassigned using the Reassign button in the Advanced Worklist, Personal Worklist, or self-service home page. The Reassign button in these pages will still be displayed, but an error message will appear if users attempt to reassign notifications for which the #HIDE_REASSIGN attribute has been set. See: To View Notifications from the Advanced Worklist and To View Notifications from the Personal Worklist.

Additionally, with this attribute you can specify whether or not the notification can still be reassigned through vacation rules. You can choose to both hide the Reassign button and prevent reassignment through vacation rules. In this case Oracle Workflow does not apply any vacation rules to reassign those notifications, but simply delivers the notifications to the worklist of the original recipient. You can also choose to hide the Reassign button but still allow reassignment through vacation rules.

The #HIDE_REASSIGN attribute must be either of type text or lookup.

• To hide the Reassign button in the Notification Details page, and to prevent reassignment from the Advanced Worklist, Personal Worklist, and self-service home page, as well as through vacation rules, set the value of this attribute to Y.

• To hide the Reassign button in the Notification Details page, and to prevent reassignment from the Advanced Worklist, Personal Worklist, and self-service home page, but still allow reassignment through vacation rules, set the value of this attribute to B.

• To display the Reassign button in the Notification Details page, and to allow reassignment from the Advanced Worklist, Personal Worklist, self-service home page, and vacation rules, set the value to N.

• If you always want to restrict reassignment for notifications using a particular message, specify the value Y or B as a constant.

• If you only want to restrict reassignment in certain cases, specify an item type attribute as the value. Then include logic in your workflow process that dynamically determines at runtime whether reassignment should be permitted or restricted and sets the item type attribute to Y, B, or N, accordingly.

#HIDE_MOREINFO Attribute

You can use a special message attribute with the internal name #HIDE_MOREINFO to hide the Request Information button in the Notification Details page. When users view a notification that requires a response from their Worklist page, the response region in the Notification Details page includes the Request Information button by default. If you want to prevent users from requesting more information about a notification, you can add the #HIDE_MOREINFO attribute to control whether the Request Information button is displayed or hidden.

The #HIDE_MOREINFO attribute must be either of type text or lookup. To hide the Request Information button, set the value of this attribute to Y. To display the Request Information button, set the value to N.

• If you always want to hide the Request Information button for notifications using a particular message, specify the value Y as a constant.

• If you only want to hide the Request Information button in certain cases, specify an item type attribute as the value. Then include logic in your workflow process that dynamically determines at runtime whether the button should be hidden or displayed and sets the item type attribute to Y or N, respectively.

#MORE_INFO_PARTICIPANTS Attribute

You can use a special message attribute with the internal name #MORE_INFO_PARTICIPANTS to designate additional users or roles from whom the notification recipient can request more information. When a user chooses to request more information about a notification, the Request More Information From page or the e-mail request template includes a list of workflow participants to whom the user can choose to send the request. By default, the list of workflow participants includes the following:

• The owner of this workflow process and the owner of the parent process, if this process has a parent

• The current recipient roles of all notifications sent by this workflow process or its parent process

• The original recipient roles of all notifications sent by this workflow process or its parent process, if any notifications were reassigned

• The From roles for all notifications sent by this workflow process or its parent process

If you want to designate additional users as participants from whom information about this message can be requested, create a role whose members are all the users that you want to add, and assign this role as the value for the #MORE_INFO_PARTICIPANTS attribute. Then, when the notification recipient chooses to request more information, the users that belong to that role are added to the default list of workflow participants.

The #MORE_INFO_PARTICIPANTS attribute must be of type role and must have a source of Send. You should specify an item type attribute as the value for the #MORE_INFO_PARTICIPANTS attribute and include logic in your workflow process that dynamically sets that item type attribute to the role you want at runtime. If no existing role meets your needs, you can include logic in your process to create an ad hoc role at runtime and add the users you want to that role.

See: To Respond to an HTML E-mail Notification and To Request More Information From Another User.

#FROM_ROLE Attribute

You can use a special message attribute with the internal name #FROM_ROLE to specify the role that is the source of a notification. For example, if you have a notification that informs an approver that a requisition was submitted, you can set the requisition preparer as the From Role for the message.

If a notification with this attribute is reassigned through the Worklist Web pages, Oracle Workflow automatically sets the From Role to the previous recipient when sending the notification to the new recipient. Also, Oracle Workflow automatically sets the From Role for a request for more information to the user who sent the request, and sets the From Role for a response providing more information to the user who sent the response.

The From Role for each notification is displayed in the Worklist Web page and in e-mail notifications to give users additional information for reviewing and responding to the notifications. Additionally, the Notification Search page and Personal Worklist let you search for notifications based on the From Role. See: To View Notifications from the Advanced Worklist, Searching for Users' Notifications in Oracle E-Business Suite, and To View Notifications from the Personal Worklist.

To enhance security, Oracle Workflow does not allow a notification to be reassigned to the role specified as its From Role.

The #FROM_ROLE attribute must be of type role and must have a source of Send. The display name and description of the attribute should both be From Role. You should specify an item type attribute as the value for the #FROM_ROLE attribute and include logic in your workflow process that dynamically sets that item type attribute to the role you want at runtime.

#WF_SIG_POLICY Attribute

You can use a special message attribute with the internal name #WF_SIG_POLICY to require that a user's response to a notification be signed electronically. This electronic signature is analogous to a written signature. If you define a notification to require an electronic signature, users must respond to the notification from the Notification Details Web page and enter the appropriate type of signature. Otherwise, the response will not be considered valid.

• If you define a notification to require a password-based signature, users must sign their response by entering their Oracle E-Business Suite user name and password.

• If you define a notification to require a certificate-based digital signature, users must sign their response with a valid X.509 certificate issued by a certificate authority. After the signed response is submitted, Oracle Workflow performs the following steps:

  • Verifies that the signature was well formed, that it was created with a private key corresponding to the offered signing certificate, and that it is signing the plain text that it purports to sign.

  • Confirms that this user is authorized to sign the notification by checking that the certificate is assigned to a user who is a member of the recipient role for the notification.

  • Confirms that the certificate used to create the signature was valid at the time the signature was received, meaning it had not expired or been revoked. To validate a certificate, Oracle Workflow checks that the certificate does not appear on a certificate revocation list (CRL) issued by the certificate authority after the time the signature was received.

The signed response text for both types of signatures contains the notification header information and the response values entered by the user. You can optionally require the signed response text to include the notification message body as well.

The #WF_SIG_POLICY attribute must be either of type text or lookup.

• To require a password-based signature without including the message body in the signed response text, set the value of the #WF_SIG_POLICY attribute to PSIG_ONLY.

• To require a password-based signature and include the message body in the signed response text, set the value of the #WF_SIG_POLICY attribute to PSIG_BODY.

• To require a certificate-based digital signature without including the message body in the signed response text, set the value of the #WF_SIG_POLICY attribute to PKCS7X509_ONLY.

• To require a certificate-based digital signature and include the message body in the signed response text, set the value of the #WF_SIG_POLICY attribute to PKCS7X509_BODY.

• If you set the value to DEFAULT, leave the value blank, or if you do not define a #WF_SIG_POLICY attribute for the message, Oracle Workflow performs the default response processing that does not require a signature.

For ease of maintenance, you can define the #WF_SIG_POLICY attribute with a type of lookup and assign it the predefined Signature Policy lookup type provided in the Standard item type. The Signature Policy lookup type contains five lookup codes with the display names Password Signature, Password Signature With Body, X509 Signature, X509 Signature With Body, and Default, representing the values PSIG_ONLY, PSIG_BODY, PKCS7X509_ONLY, PKCS7X509_BODY, and DEFAULT, respectively.

You can also define the #WF_SIG_POLICY attribute with a type of text. In this case, you must manually maintain the values that you set for this attribute.

You can either specify a constant value for the #WF_SIG_POLICY attribute, or specify an item type attribute as the value and include logic in your workflow process that dynamically determines at runtime whether a signature should be required or not and sets that item type attribute accordingly.

Oracle Workflow records the status of requested and submitted signatures in the Signature Evidence Store, for both password-based signatures and certificate-based digital signatures. You can search for signatures in the Signature Evidence Store to check the status of a signature request and review details that provide evidence of the signature. If your business logic requires a signature to be validated as a prerequisite for other activities, your workflow can include a notification to an administrator to confirm the signature status before continuing. See: Reviewing Electronic Signature Details.

To preserve electronic signature evidence for future reference, the Purge Obsolete Workflow Runtime Data concurrent program and the Oracle Workflow purging APIs by default do not delete any notifications that required signatures or their associated signature information. If you anticipate needing access to signature evidence after the associated workflow processes are complete, ensure that you choose to preserve signature data when purging. If you do not need to maintain signature evidence, you can choose to delete signature-related information when purging. See: Purging Workflow Data and Workflow Purge APIs.

For more information, see: Setting Up for Electronic Signatures, Electronic Signatures, Viewing Responses, and NtfSignRequirementsMet.

#WF_SIG_ID Attribute

You can specify an electronic signature policy for notifications by defining the #WF_SIG_POLICY message attribute. If you specify a signature policy that requires an electronic signature to confirm a user's response to a notification, Oracle Workflow creates another message attribute named #WF_SIG_ID after the notification is signed. The #WF_SIG_ID attribute stores the identifier for the signature, which you can use to reference information about the signature later if necessary. This attribute is of type text and has a source of 'Respond'.

#WF_SECURITY_POLICY Attribute

You can use a special message attribute with the internal name #WF_SECURITY_POLICY to control whether notifications that include sensitive content can be sent in e-mail. If you specify that a notification's content must not be sent in e-mail, users receive an e-mail message that only informs them that they must access the notification through the Notification Details Web page instead to view its content and respond. To access the Notification Details page, users can either log into Oracle E-Business Suite separately, or, if their notification preference includes HTML attachments, use the Notification Detail Link. See: Reviewing Notifications via Electronic Mail.

The #WF_SECURITY_POLICY attribute must be of type text. To prevent notification content from being sent in e-mail, set the value of the #WF_SECURITY_POLICY attribute to NO_EMAIL. If you set the value to EMAIL_OK or DEFAULT, leave the value blank, or if you do not define a #WF_SECURITY_POLICY attribute for the message, Oracle Workflow sends the full notification content in e-mail to users whose notification preference is set to receive e-mail.

You can either specify a constant value for the #WF_SECURITY_POLICY attribute, or specify an item type attribute as the value and include logic in your workflow process that dynamically determines at runtime whether the notification content can be sent in e-mail or not and sets that item type attribute accordingly.

Header Attributes

You can use special header message attributes to display key information in the notification header region of the Notification Details page. Header attributes are also displayed at the beginning of e-mail notifications. To identify a message attribute as a header attribute, you must define an internal name for it that begins with #HDR_ using the following format:

#HDR_<name>

The display order of any header attributes in the Notification Details page or the e-mail notification is determined by the sequence of those attributes within the navigation tree in the Workflow Builder. The display name of each header attribute will appear as a label before the attribute value in the notification header region. You can either specify a constant value for each attribute, or specify an item type attribute as the value and include logic in your workflow process that dynamically sets the item type attribute value at runtime.

#HDR_REGION Attribute

The notification header region by default contains general message information such as the from role, recipient, sent date, due date, and notification ID, together with any special header attributes defined for the notification, and, if a notification with the #ATTACHMENTS attribute is viewed in the Notification Details page, links to the specified Oracle E-Business Suite attachments. You can optionally use a special message attribute with the internal name #HDR_REGION to replace this default header with a custom header region.

Your custom header must be defined as an Oracle Application Framework region. For more information about building an Oracle Application Framework region, refer to the Oracle Application Framework Developer's Guide, available from My Oracle Support Knowledge Document 1315485.1.

The #HDR_REGION attribute must be of type document and must have a source of Send. Set the value of this attribute to a Java Server Page (JSP) call that references your custom header region. For detailed instructions on how to specify the attribute value, see: Embedding Oracle Application Framework Regions in Messages.

#RELATED_APPL Attribute

The Related Applications region in Oracle Application Framework-based notifications by default contains icons with links to attached URLS, documents, or forms. You can optionally use a special message attribute with the internal name #RELATED_APPL to replace this default region with a custom Related Applications region.

Your custom Related Applications region must be defined as an Oracle Application Framework region. For more information about building an Oracle Application Framework region, refer to the Oracle Application Framework Developer's Guide, available from My Oracle Support Knowledge Document 1315485.1.

The #RELATED_APPL attribute must be of type document and must have a source of Send. Set the value of this attribute to a Java Server Page (JSP) call that references your custom region. For detailed instructions on how to specify the attribute value, see: Embedding Oracle Application Framework Regions in Messages.

#ATTACHMENTS Attribute

In Oracle E-Business Suite, you can link attachments to a data record. For a workflow notification that includes an embedded Oracle Application Framework region, you can optionally use a special message attribute with the internal name #ATTACHMENTS to include such Oracle E-Business Suite attachments when the notification is sent by e-mail. In this case, the recipient does not need to log into Oracle E-Business Suite to view the attachments. Oracle E-Business Suite attachments of type Short Text and Long Text are attached to the e-mail message as text files, Oracle E-Business Suite attachments of type URL are attached as HTML files, and Oracle E-Business Suite attachments of type File are attached as the file format in which they were uploaded.

If the recipient views the notification in the Notification Details page, the notification header displays an Attachment(s) heading with links to the Oracle E-Business Suite attachments.

The #ATTACHMENTS attribute must be of type document and must have a source of Send. In the value for the attribute, specify the entity with which the attachments are associated and the primary keys used to identify the record with which the attachments are associated. Specify the #ATTACHMENTS attribute in the following format:

FND:entity=<entity>&pk1name=<primary_key_1_name>&pk1value=<primary_key_1_value>&pk2name=<primary_key_2_name>&pk2value=<primary_key_2_value>&pk3name=<primary_key_3_name>&pk3value=<primary_key_3_value>&pk4name=<primary_key_4_name>&pk4value=<primary_key_4_value>&pk5name=<primary_key_5_name>&pk5value=<primary_key_5_value>

In the attribute value, replace the variables as follows:

• <entity> - Specify the entity name as it appears in the DATA_OBJECT_CODE column in the FND_DOCUMENT_ENTITIES table.

• <primary_key_1_name>, <primary_key_2_name>, <primary_key_3_name>, <primary_key_4_name>, and <primary_key_5_name> - Specify the names of the primary keys as they appear in the columns PK1_COLUMN, PK2_COLUMN, and so on in the FND_DOCUMENT_ENTITIES table.

• <primary_key_1_value>, <primary_key_2_value>, <primary_key_3_value>, <primary_key_4_value>, and <primary_key_5_value> - Specify the values of the primary keys as they appear in the columns PK1_VALUE, PK2_VALUE, and so on in the FND_ATTACHED_DOCUMENTS table.

See: Using Attachments.

#HISTORY Attribute

Response-required notifications and some FYI notifications include an action history table. You can optionally use a special message attribute with the internal name #HISTORY to replace the default action history table provided by Oracle Workflow with a custom action history region. See: Action History.

Your custom action history table must be defined as an Oracle Application Framework region, or as a PL/SQL or PL/SQL CLOB document that contains text or HTML. For more information about building an Oracle Application Framework region, refer to the Oracle Application Framework Developer's Guide, available from My Oracle Support Knowledge Document 1315485.1.

The #HISTORY attribute must be of type document and must have a source of Send. For an Oracle Application Framework region, set the value of this attribute to a Java Server Page (JSP) call that references your custom action history region. For detailed instructions on how to specify the attribute value, see: Embedding Oracle Application Framework Regions in Messages.

For a PL/SQL or PL/SQL CLOB document, set the attribute value to the procedure and document ID from which the document is generated. See: To Define a Document Attribute.

#SUBMIT_COMMENTS Attribute

The action history region for notifications begins with a row for the initial submission of the process, when the notification is first sent. You can optionally use a special message attribute with the internal name #SUBMIT_COMMENTS to display comments from the process owner for this initial action. See: Action History.

The #SUBMIT_COMMENTS attribute must be of type text and must have a source of Send. You should specify an item type attribute as the value for the #SUBMIT_COMMENTS attribute and include logic in your workflow process that dynamically sets that item type attribute to contain the comments at runtime. Ensure that you provide a way for the process owner to enter the comments when submitting the process and store the comments in the appropriate item type attribute.

#RELATED_HISTORY Attribute

You can use a special message attribute with the internal name #RELATED_HISTORY to include the action history of one notification in another notification. For example, if a workflow process contains a notification that submits a request for approval and another notification that informs the requestor whether the request was approved or rejected, the second notification can include the action history of the first notification to show the requestor more details about the approvers' decisions.

You can include related action history in both FYI (For Your Information) and response-required notifications. Each notification can only include the related action history for one related notification. The related notification can belong to the same work item or to a different work item, identified by the item type and item key.

The notification for which you define the #RELATED_HISTORY attribute must be formatted using an embedded Oracle Application Framework region. See: Embedding Oracle Application Framework Regions in Messages.

The related action history table appears as an embedded Oracle Application Framework region. The default title for the table is Related Action History. You can optionally specify a custom title to use instead. The related action history table includes the same columns as the default action history table for a notification's own action history. See: Action History.

The #RELATED_HISTORY attribute must be of type text and must have a source of Send. Specify the value for this attribute in the following format:

{<title>}[<item_type>:<item_key>]<process_name>:<activity_label_name>

• If you want to display a custom title for the related action history table, then replace <title> with the custom title. If you want to use the default title, then you can omit {<title>} from the attribute value.

• If necessary, specify the item type and item key for the work item to which the related notification belongs.

  • If the related notification belongs to a different work item than this notification, then replace <item_type> and <item_key> with the item type and item key for that work item, respectively.

  • If the related notification belongs to a work item that is a parent of the work item to which this notification belongs, then replace <item_type> with the item type for the parent work item. In this case Oracle Workflow derives the item key automatically, so you can omit :<item_key> from the attribute value.

  • If the related notification belongs to the same work item as this notification, then you can omit [<item_type>:<item_key>] from the attribute value.

• If the activity node label name does not uniquely identify the activity node of the related notification within the item type, then replace <process_name> with the internal name of the process to which the related notification activity node belongs. If the activity node label name is unique within the item type, then you can omit <process_name>: from the attribute value.

• Replace <activity_label_name> with the label name of the related notification activity node whose action history you want to include.

For instance, the following example shows the attribute value for a related notification in another work item, fully qualified with the process name, specifying a custom table title.

{Approval History}[WFDEMO:1234]NOTIFYAPPROVER:NTF_APPROVE_REQUISITION

The following example shows the attribute value for a related notification in another work item, that is unique within its item type and does not require the process name to be specified, and that will be displayed with the default table title.

[WFDEMO:1234]NTF_APPROVE_REQUISITION

The following example shows the attribute value for a related notification in a parent work item, fully qualified with the process name, specifying a custom table title.

{Approval History}[WFDEMO]NOTIFYAPPROVER:NTF_APPROVE_REQUISITION

The following example shows the attribute value for a related notification in the same work item, fully qualified with the process name, specifying a custom table title.

{Approval History}NOTIFYAPPROVER:NTF_APPROVE_REQUISITION

The following example shows the attribute value for a related notification in the same work item, that is unique within its item type and does not require the process name to be specified, and that will be displayed with the default table title. Note that in this case only the activity node label name is required.

NTF_APPROVE_REQUISITION

You can either specify a constant value for the #RELATED_HISTORY attribute, or specify an item type attribute as the value and include logic in your workflow process that dynamically determines the related notification details at runtime and sets that item type attribute accordingly. You can also token substitute individual arguments in the #RELATED_HISTORY attribute value with other message attributes. The message attributes used for token substitution in turn can have constant values or can reference the values returned from item type attributes. See: To Token Substitute an Attribute.

For instance, the following example shows the attribute value using token substitution for a related notification in another work item, fully qualified with the process name, specifying a custom table title.

{&TITLE}[&ITEM_TYPE:&ITEM_KEY]&PROCESS_NAME:&ACTIVITY_LABEL_NAME  

In this example the values for the title, item type, item key, process name, and activity label name are derived from the values of other message attributes named TITLE, ITEM_TYPE, ITEM_KEY, PROCESS_NAME and ACTIVITY_LABEL_NAME, respectively.

Region Personalization Attributes

You can use special message attributes to apply personalizations at different levels to Oracle Application Framework regions embedded in notifications.

• #PERZ_FUNCTION_NAME - Define this attribute for a message to apply a personalization at function level to a region embedded in the notification. Set the attribute value to the function name.

• #PERZ_ORGANIZATION_ID - Define this attribute for a message to apply a personalization at organization level to a region embedded in the notification. Set the attribute value to the organization ID.

• #PERZ_LOCALIZATION_CODE - Define this attribute for a message to apply a personalization at localization level to a region embedded in the notification. Set the attribute value to the localization code.

You can also create personalizations for an Oracle Application Framework region at site level. In this case the personalizations will automatically be applied when the region appears embedded in a notification, as well as when it appears in any other location.

Notification Mailer Attributes

You can use special message attributes to control how a notification mailer generates the e-mail message for a notification, if the recipient has a notification preference to receive e-mail notifications. For example, if you want to customize notifications from a particular department, you can define these attributes for those notifications.

• #WFM_FROM - Define this attribute for a message to specify the value that appears in the From field of the message header when the e-mail notification message is delivered to a user. If the #WFM_FROM message attribute is defined for a notification, the notification mailer that sends the message will use the #WFM_FROM attribute value in the From field for that message, overriding the mailer's From parameter value.

• #WFM_REPLYTO - Define this attribute for a message to specify the address of the e-mail account that receives incoming messages, to which e-mail notification responses should be sent. If the #WFM_REPLYTO message attribute is defined for a notification, the notification mailer that sends the message will use the #WFM_REPLYTO attribute value as the reply address for that message, overriding the mailer's Reply-To Address parameter value.

• #WFM_HTMLAGENT - Define this attribute for a message to specify the base URL that identifies the HTML agent that handles HTML notification responses. This URL is required to support e-mail notifications with HTML attachments. The default URL for Oracle E-Business Suite is derived from the Applications Servlet Agent (APPS_SERVLET_AGENT) profile option. You can define a different value for a particular notification mailer in the mailer's HTML Agent parameter. You can also override any other HTML agent value by defining a different value for this attribute. If the #WFM_HTMLAGENT message attribute is defined for a notification, the notification mailer that sends the message will use the #WFM_HTMLAGENT attribute value as the HTML agent for that message, overriding both the underlying default and the mailer's HTML Agent parameter value.

  The HTML agent value for Oracle E-Business Suite should have the following format:

  http://<server_name:port>/OA_HTML/

• #WFM_LANGUAGE - Define this attribute for a message to specify the value of the NLS_LANGUAGE database initialization parameter that determines the language for the e-mail notification. Set the attribute value to a language name supported by the Oracle Database, such as ARABIC. If the #WFM_LANGUAGE message attribute is defined with a valid value for a notification, the notification mailer that sends the message will use the #WFM_LANGUAGE attribute value when generating the e-mail message, overriding the language preference of the recipient role.

• #WFM_TERRITORY - Define this attribute for a message to specify the value of the NLS_TERRITORY database initialization parameter that determines the territory-dependent formatting for the e-mail notification. Set the attribute value to a territory name supported by the Oracle Database, such as UNITED ARAB EMIRATES. If the #WFM_TERRITORY message attribute is defined with a valid value for a notification, the notification mailer that sends the message will use the #WFM_TERRITORY attribute value when generating the e-mail message, overriding the territory preference of the recipient role.

  Note: The #WFM_LANGUAGE and #WFM_TERRITORY attributes function independently of each other. If you define only one of these attributes with an overriding value for the corresponding NLS parameter, the notification mailer still uses the recipient role's preference for the other parameter.

  These message attributes are optional. You need to define them only when you do not want to use the recipient role's own language and territory preferences to generate the e-mail notification.

  Note: The notification mailer can only use installed languages. If you set the #WFM_LANGUAGE attribute to a language that is not installed, the notification mailer generates the e-mail notification with the base language for the database.

• #WFM_RESET_NLS - Define this attribute for a message to specify whether the notification mailer should encode the message with character encoding according to the notification recipient's preferred language.

  • Set the attribute value to Y to encode the message with character encoding according to the language specified in the notification recipient's user preferences. Oracle Workflow takes the character encoding for the language either from the WF_LANGUAGES table or from the override settings specified in the Character Encoding Configuration page.

  • Set the attribute value to N to send the message in the default character encoding for the database or the override character encoding specified in the Character Encoding Configuration page.

  If the #WFM_RESET_NLS message attribute is defined with a valid value for a notification, the notification mailer that sends the message will use the #WFM_RESET_NLS attribute value when generating the e-mail message, overriding the mailer's Reset NLS parameter value. For more information about how Oracle Workflow determines which character encoding to use, see: Configuring Character Encoding for Notification Mailers.

  Note: The #WFM_RESET_NLS attribute takes effect at the notification message level. If the recipient role for the notification has multiple members, then the notification mailer applies the #WFM_RESET_NLS attribute value for every e-mail recipient.

  Note: The notification mailer can only use installed languages. If you set the #WFM_LANGUAGE attribute for a message to a language that is not installed, then the base language for the database takes effect. If you also define the #WFM_RESET_NLS attribute for that message, it affects the encoding of the e-mail message only for that base language.

• #WFM_NODENAME - Use this attribute in conjunction with the #WFM_FROM and #WFM_REPLYTO attributes, if required, to indicate that the response to a notification should be processed by a different mailer node than the one that sends the notification. If the #WFM_NODENAME message attribute is defined for a notification, the response template generated from the notification will include the #WFM_NODENAME attribute value in the NID line, overriding the sending mailer's Mailer Node Name parameter value.

• #WFM_HTML_DELIMITER - Define this attribute for a message to specify which characters the notification mailer uses to delimit response values in response templates for HTML-formatted e-mail notifications. Valid values for the #WFM_HTML_DELIMITER attribute are:

  • DEFAULT - The notification mailer uses the default delimiters, currently set as the single quote (') for both the opening and the closing delimiter.

  • APOS - The notification mailer uses the single quote, or apostrophe ('), as both the opening and the closing delimiter. This setting is currently the same as the default.

  • QUOTE - The notification mailer uses the double quote (") as both the opening and the closing delimiter.

  • BRACKET - The notification mailer uses the left bracket ([) as the opening delimiter and the right bracket (]) as the closing delimiter.

  Using single quotes as the delimiters accommodates e-mail applications that cannot process double quotes in the <A HREF="mailto:"> tag for the response template link, but can accept single quotes. However, if you want users to be able to use apostrophes or single quotes in their response values without entering an escape character, you can use double quotes or brackets as the delimiters, depending on what your e-mail application supports. For example, Microsoft Outlook Express does not support using double quotes, so if you use Microsoft Outlook Express, you can set the #WFM_HTML_DELIMITER attribute to DEFAULT, APOS, or BRACKET, but you should not set this parameter to QUOTE. See: To Respond to an HTML E-mail Notification.

  Note: If the #WFM_HTML_DELIMITER attribute is set to an invalid value, the notification mailer throws an exception and uses the default delimiters instead.

  If the #WFM_HTML_DELIMITER message attribute is defined for a notification, the notification mailer that sends the message will use the #WFM_HTML_DELIMITER attribute value to determine which delimiters to use for that notification, overriding the mailer's HTML_DELIMITER parameter value.

  Note: The #WFM_HTML_DELIMITER attribute only controls the response templates for HTML-formatted notifications. This attribute does not apply to plain text notifications.

For more information, see: Notification Mailer Configuration Wizard, Setting Up Notification Mailers. and Locale Data, Oracle Database Globalization Support Guide.

Notification Mailer Message Template Attributes

You can use special message attributes to specify which message templates a notification mailer uses to generate the e-mail message for a notification, if the recipient has a notification preference to receive e-mail notifications. For example, if you want to customize notifications from a particular department, you can define these attributes for those notifications. The templates specified in these attributes for a particular notification override the templates specified in the configuration parameters for a notification mailer.

You can create your own message templates by using the Workflow Builder to define skeleton messages within an item type. See: Modifying Your Message Templates.

The value for a message template attribute must be specified in the following format:

<item_type_internal_name>:<message_internal_name>

For example, to specify the Workflow Open Mail (Templated) message within the System: Mailer item type, you would enter the following value:

WFMAIL:OPEN_MAIL

You can either specify a constant value for a message template attribute, or specify an item type attribute as the value and include logic in your workflow process that dynamically determines at runtime which message template to use and sets that item type attribute accordingly.

You can define the following attributes to specify templates to be used for a notification message at various stages in e-mail notification processing.

• #WFM_OPEN_MAIL - Specify the template to use for e-mail notifications that require a response, if you are using the templated response method.

• #WFM_OPEN_MAIL_DIRECT - Specify the template to use for e-mail notifications that require a response, if you are using the direct response method.

  Note: If you defined the #WF_SIG_POLICY attribute for a message to require an electronic signature in users' responses, you do not need to define the #WFM_OPEN_MAIL or #WFM_OPEN_MAIL_DIRECT attributes for that message. The notification mailer always uses the Workflow Signature Required Mail message in the System: Mailer item type as the template for notifications that require an electronic signature, overriding any other template setting.

• #WFM_OPEN_MAIL_FYI - Specify the template to use for e-mail notifications that do not require a response.

• #ATTACHED_URLS - Specify the template to use to create the Notification References attachment for HTML-formatted notification messages that include URL attributes with Attach Content checked.

• #WFM_CANCELED - Specify the template to use to inform the recipient that a previously sent notification is canceled.

• #WFM_OPEN_INVALID - Specify the template to send to a user when the user responds incorrectly to a notification.

• #WFM_CLOSED - Specify the template to use to inform the recipient that a previously sent notification is now closed.

• #WFM_OPEN_MORE_INFO - Specify the template to use to send a request for more information from one user to another user.

See: Notification Mailer Configuration Wizard.

Additional E-mail Recipient Attributes

You can use special message attributes to specify additional recipients for a notification e-mail message, if the primary recipient has a notification preference to receive individual e-mail notifications.

• #WFM_CC - Define this attribute to specify one or more secondary recipients for a notification e-mail message. These recipients are stored in the CC (Carbon Copy) field of the message header.

• #WFM_BCC - Define this attribute to specify one or more additional recipients for a notification e-mail message whose identities are not included in copies of the message sent to the primary and secondary recipients. These recipients are stored in the BCC (Blind Carbon Copy) field of the message header.

The #WFM_CC and #WFM_BCC attributes must be of type text and must have a source of Send. Specify the attribute value as a list of the e-mail addresses or role names of the additional recipients, separated by semicolons (;).

• If you specify e-mail addresses, each address must be fully qualified with a valid domain. If any addresses are not fully qualified, the notification mailer treats them as role names.

• If you specify role names, ensure that those roles have valid e-mail addresses defined.

You can either specify a constant value for each attribute, or specify an item type attribute as the value and include logic in your workflow process that dynamically determines the e-mail address at runtime and sets that item type attribute accordingly.

The notification mailer sends the CC and BCC recipients copies of the e-mail message generated for the primary recipient. However, the CC and BCC recipients are not added to the recipient role for the notification in the Notification System.

• CC and BCC recipients receive the notification e-mail message only if the primary recipient has a notification preference of MAILTEXT, MAILHTML, MAILHTM2, or MAILATTH, and the format of the e-mail is determined by the notification, language, and territory preferences of the primary recipient.

• If the primary recipient has one of the listed notification preferences, the notification mailer sends the notification e-mail message to CC and BCC recipients irrespective of their own notification preferences. However, the notification mailer does check whether any CC or BCC recipients that are specified as role names have a notification preference of DISABLED, which indicates that the e-mail address on record for the role is invalid. To help avoid unnecessary processing, the notification mailer does not send further e-mails to roles marked with the DISABLED preference. See: Outbound Notification Mailer Processing.

• If the primary recipient is a role with multiple members, each of whom receives an individual notification e-mail message, then the CC and BCC recipients receive copies of all the e-mail messages sent to all the primary recipient role members.

• The notification does not appear in the worklists of CC and BCC recipients.

• CC and BCC recipients do not receive copies of any requests for more information about a notification, nor of any answers providing more information.

Adding CC and BCC recipients is recommended only for FYI notifications. If you do add CC or BCC recipients to a response-required notification, consider whether the additional recipients should be able respond to the notification, and set up your security options accordingly.

• If the notification includes the Notification Detail Link attachment and you enable guest access to the Notification Details page, then CC and BCC recipients can use the Notification Detail Link attachment to access the Notification Details page, and view and respond to the notification there. If you do not want CC and BCC recipients to access the Notification Details page, then you should disable guest access, or require your users to set notification preferences that do not include the Notification Detail Link attachment, such as MAILTEXT or MAILHTM2.

• If the notification allows responses by e-mail and you select the Allow Forwarded Response mailer configuration parameter, then CC and BCC recipients can respond to the notification by e-mail. If you do not want CC and BCC recipients to respond by e-mail, deselect the Allow Forwarded Response mailer configuration parameter, or choose notification options that require users to respond through the Notification Details page. For example, users must use the Notification Details page to respond to notifications that require electronic signatures and notifications marked as including secure content not sent by e-mail. See: #WF_SIG_POLICY_ATTRIBUTE and #WF_SECURITY_POLICY Attribute.

• If the notification requires an electronic signature, then only a primary recipient who provides a valid signature in the Notification Details page can respond. In this case CC and BCC recipients cannot respond to the notification.

See: E-mail Notification Security.

Approvals Data Services Attributes

If you configure messages for use with approvals data services, you can use special message attributes to control how the approval notifications appear in the Oracle Mobile Approvals for Oracle E-Business Suite app. These message attributes let you specify how to handle content for a message that is used as a boilerplate template to send approval notifications from multiple notification activities for different approval objects.

• #APPROVALS_GROUP - If a message is used by multiple notification activities, define this attribute for the message to specify the approvals group value that identifies the approval type to which the various notifications sent from this message belong. For each notification activity that uses this message, include logic in your workflow process to set the value of the #APPROVALS_GROUP attribute to a value representing the appropriate approval type. See: Approval Types.

• #APPROVALS_OBJECT - If a message is used by multiple notification activities for different approval objects, define this attribute for the message to specify the approval object to which the various notifications sent from this message pertain. For each notification activity that uses this message, include logic in your workflow process to set the message attribute value to a value that represents the approval object for the notification. You can then use this message attribute in rules that control which detail regions are displayed in the approval notification body details. See: To prepare a region for conditional display.

For more information, see: Identifying Approval Notification Content.

Example 'Respond' Message Attributes

Following are examples of how the Notification System generates the Response section of an e-mail notification using a sample set of 'Respond' message attributes that have no default values.

The following table lists some sample 'Respond' message attributes.

Sample Respond Attributes

For the templated response method, the following boilerplate text is used to generate the Response template section of an e-mail notification:

<Description> 
<Display Name>: " "
          <list of lookup codes>

Portion of Resulting Response Template as Shown in a Templated Response E-mail Notification

For the direct response method, the following boilerplate text is used to generate the Response section of an e-mail notification:

Enter the <Display Name> on line <Sequence>. <Description> <Type_Hint> 

<Display Name> is replaced with the Display Name of the message attribute. <Sequence> is replaced with the relative sequence number of the 'Respond' message attribute as it appears in the Navigator tree among all 'Respond' message attributes (that is, the presence of 'Send' message attributes is ignored when determining the sequence). <Description> is replaced with the Description of the message attribute. In addition, <Type_Hint> is replaced with a hint statement if the message attribute matches a data type that has a hint. The following table shows the data types with hints and the corresponding hint statements.

Data Type Hints

Portion of Resulting Response Section as Shown in a Direct Response E-mail Notification

Embedding Oracle Application Framework Regions in Messages

If you have Oracle Application Framework set up in Oracle JDeveloper for custom development, you can embed Oracle Application Framework regions in a notification message. To embed a region, define a message attribute whose value is a Java Server Page (JSP) call that references the region.

The message attribute representing the region must be of type document and must have a source of Send. You can assign the attribute any appropriate internal name, display name, and description.

Specify the value for the attribute in the following format:

JSP:/OA_HTML/OA.jsp?OAFunc=<Function_Name> 

where <Function_Name> is the self-service function name for the region you want to embed in the notification, as registered in the Form Functions window in Oracle E-Business Suite. For example:

JSP:/OA_HTML/OA.jsp?OAFunc=EMBED_WL_FUNC

To pass parameters to the region, specify the value for the attribute in the following format:

JSP:/OA_HTML/OA.jsp?OAFunc=<Function_Name>&<Name1>=<Value1>
&<Name2>=<Value2>...

where <Function_Name> is the function name for the region, <Name1> and <Value1> are the parameter name and value for the first parameter, <Name2> and <Value2> are the parameter name and value for the second parameter, and so on. For example:

JSP:/OA_HTML/OA.jsp?OAFunc=EMBED_WL_FUNC&Order_Type=12345

You can set the value for the message attribute in the following ways:

• Specify the complete JSP call as a constant default value for the message attribute.

• Specify an item type attribute of type document as the message attribute value, and include logic in your workflow process that dynamically sets the item type attribute value at runtime. This method lets you dynamically set the complete JSP call.

• Use token substitution in the message attribute value to dynamically set the function name within the JSP call.

  • Create an item type attribute for the function name.

  • Create an additional message attribute for the function name, and specify the corresponding item type attribute as the value of that message attribute.

  • Include logic in your workflow process that dynamically sets the item type attribute value to the appropriate function name at runtime.

  • Specify the value for the message attribute representing the region in the following format:

    JSP:/OA_HTML/OA.jsp?OAFunc=-&funcname_attr-
    

    where funcname_attr is the internal name of the message attribute that specifies the function name.

• Use token substitution in the message attribute value to dynamically set the parameter values for the function within the JSP call. In this case you must specify the function name and the parameter names as constants within the JSP call, and token substitute only the parameter values.

  • Create an item type attribute for each parameter value.

  • Create an additional message attribute for each parameter value, and specify the corresponding item type attribute as the value of that message attribute.

  • Include logic in your workflow process that dynamically sets the item type attribute values to the appropriate parameter values at runtime.

  • Specify the value for the message attribute representing the region in the following format:

    JSP:/OA_HTML/OA.jsp?OAFunc=<Function_Name>&<Name1>
    =-&msgattr1-&<Name2>=-&msgattr2-...
    

    where <Function_Name> is the function name for the region, <Name1> and <Name2> are the first and second parameter names, msgattr1 and msgattr2 are the internal names of the message attributes that specify the first and second parameter values, and so on.

To embed the region in the message, enter the token for the message attribute in the HTML body for the message. A message can include multiple regions, which will be displayed in the sequence in which their tokens appear in the HTML Body field. Additionally, the message can include calls to the special message function WF_NOTIFICATION() to produce a table of message attributes or an action history table, which will also be rendered as Oracle Application Framework regions. See: WF_NOTIFICATION() Message Function.

Leave the Text Body field blank for an Oracle Application Framework region message. Oracle Workflow does not use the text body for such messages. Instead, a text version of the message is derived directly from the included regions. Note that non-text content such as images, links, or special HTML formatting will not appear in the text version of a region.

Follow these guidelines when you are developing an Oracle Application Framework region for inclusion in a notification message:

• Oracle Workflow notifications support embedded Oracle Application Framework regions only. You cannot include an entire Oracle Application Framework page.

• The region style must be Stack Layout. This region style lets users personalize the region with Oracle Application Framework Personalization.

• Ensure that the event handling in the controllers for the embedded Oracle Application Framework region does not interfere with the event handling of the region controller for the main message body. To avoid such interference, when handling any events in the controller code, you must qualify those events with the region associated with the controller.

• The embedded region must be complete within itself. You should associate the region with its own application module (AM) and assign it a region title.

• You should retain the calling AM in the code of the application that owns the region. For example, if you create a custom attachments region to be displayed in a notification in the Notification Details page, the root AM as well as the subsequent nested AMs should be retained in the owning application's controllers and should not be refreshed. This is required to avoid issues when the owning application returns control to Oracle Workflow.

• The embedded region must be a view-only region. That is, it cannot contain elements that allow user input, such as buttons.

• The embedded region must not contain any information that is specific to a particular user session.

• The embedded region must not perform a form submit. The embedded region also must not include any Oracle Application Framework components that perform an implicit form submit, such as subtabs or hideShow beans.

• If you do not want to send an embedded region in e-mail, you can exclude the message body from notification e-mail messages by assigning the notification a message template that directs recipients to access the notification through the Worklist Web pages instead.

  • For a notification that requires a response, define the special message attributes #WFM_OPEN_MAIL and #WFM_OPEN_MAIL_DIRECT, and set the values of these attributes to WFMAIL:VIEW_FROMUI to use the Workflow View From UI message template.

  • For a notification that does not require a response, define the special message attribute #WFM_OPEN_MAIL_FYI, and set the value of this attribute to WFMAIL:VIEW_FROMUI_FYI to use the Workflow View FYI From UI message template.

  See: Notification Mailer Message Template Attributes, Workflow View From UI Message, and Workflow View FYI From UI Message.

• For usability reasons, we recommend that if your Stack Layout region includes a Table Layout region, you should restrict to 200 the number of rows returned from the query for the Table Layout region.

  If your Stack Layout region includes a region in the Table Layout region style, the Notification Details page displays the Table Layout region with the Next and Previous rowset functionality available when appropriate. However, because e-mail clients cannot interpret the rowset functionality, e-mail notifications display the Table Layout region with static row data, which is restricted to 200 rows.

• Do not enable sorting or navigation features for table components programmatically at runtime.

• Register your Oracle Application Framework region as a self-service function (non-form function) in the Form Functions window in Oracle E-Business Suite. The internal name that you define for the function is the function name that you must include in the message attribute value to reference the region. See: Form Functions Window, Oracle E-Business Suite Developer's Guide.

  When you register the function, enter the HTML Call in the Web HTML tabbed region of the Form Functions window, using the following format:

  OA.jsp?page=/<directory_path>/<Region_Code>
  &akRegionApplicationId=<Region_Application_ID>
  

  For example:

  OA.jsp?page=/oracle/apps/fnd/wf/worklist/webui/
  WFNTFWORKLIST&akRegionApplicationId=601
  

For more information about building an Oracle Application Framework region, refer to the Oracle Application Framework Developer's Guide, available from My Oracle Support Knowledge Document 1315485.1.

When you configure a notification mailer, you can set certain parameters to control how the notification mailer includes Oracle Application Framework content in e-mail notifications. For example, you can specify the user, responsibility, and application through which a notification mailer accesses Oracle Application Framework content. You can also specify whether to attach any stylesheet and images referenced in Oracle Application Framework regions to e-mail notifications, or simply display the stylesheet and image references as URLs. See: Notification Mailer Configuration Wizard.

You can use the Workflow Mailer URL Access Tester page to test whether Oracle Application Framework content can be generated correctly for e-mail notifications. See: Testing Mailer URL Access.