Workflow Notifications to Users/Roles

Workflow Notifications are sent to the Users/Roles for which setup has been done through Oracle Apps.
Its possible to create Users/Roles using workflow API and all this information is stored in below Oracle
Database tables

FND_USERS:
stores the Oracle application user data that is setup through System administrator>User. It links
employee id to the User id, along with email id


WF_USERS/WF_LOCAL_USERS:
stores User data along with email id to which Notification is to be sent. When A new user is
defined in oracle apps along with fnd_user table a new record is inserted into this table.

WF_ROLES/WF_LOCAL_ROLES:
store roles information

WF_USER_ROLES:
Associations of users with the roles

To sent a notification to a particular User following steps need to be performed
1. Add a Notification node to the workflow process
2. Create a attribute of type ROLE in workflow and at the node just before sending the notification
   setup the value of attribute using below api
            wf_engine.SetItemAttrText
                (itemtype        => x_item_type
                ,itemkey        => x_item_key
                ,aname            => 'MAIN_USER'
            ,avalue            => x_user);
   Here x_user is user_name/name fetched from fnd_users/wf_users table for that person

3. Open the Notification node in the process and on 'Node' tab select the Performer as the
   Type "Item Attribute" and value as attribute.
  
Whenever the workflow process is initiated and notification is sent, the table WF_NOTIFICATIONS
is populated with RECIPIENT_ROLE as X_USER


Notification to multiple Users:
In workflow if you need to send a Notification at once to different Users, you need
to create a role using below API.
-- Create adhoc role
wf_directory.createadhocrole
    (role_name             => x_role_name
    ,role_display_name        => x_role_name
    ,LANGUAGE                       => NULL
    ,territory                      => NULL
    ,role_description               => 'MAIN_ROLE'
    ,notification_preference    => 'MAILHTML'
    ,role_users                    => NULL
    ,email_address                    => NULL
    ,fax                        => NULL
    ,status                => 'ACTIVE'
    ,expiration_date        => SYSDATE+ 60
    ,parent_orig_system         => 'WF_LOCAL_ROLES'
    ,parent_orig_system_id        => 0
    ,owner_tag            => NULL);


Once role is created now add Users to Role using below API. In below API the parameter
role_users is passed with list of USER_NAME separated by space.
--Add Users to Role
wf_directory.AddUsersToAdHocRole
    (role_name     =>x_role_name,
     role_users     =>'Username1 Username2 Username3');

To verify the details please check with below queries

--Check the Role name
select * from wf_roles where name like x_role_name;

--Check the User associated with the Role
select * from wf_user_roles where role_name like x_role_name;

Error in Workflow ORA-04061: existing state of has been invalidated

Working with workflows can be tough when you get errors that are really difficult to debug. As I was recently working on one of the custom workflow, I encountered the below error


"Error in Workflow /203462 ORA-04061: existing state of has been invalidated"

First thing I did was to check if the Package that has been called through workflow was in valid state and to my surprise it was. After a lot of research I came to know that this is a bug in Workflow.

Cause:
If you are designing/modifying a workflow process, the workflow works fine for certain instances and you modify the Package and recompile it. And now you run the workflow process you get the above error. Recompilation of package spec/body called through workflow is the main reason you will end up with this error.
This happens as workflow fails to look at the new status of the package after compilation and it continues to look at the old SGA data.

Solution:
1. One simple way to get away with this error without involving DBA/Sysadmin team is to rename the package that is being called through the workflow and accordingly modify the workflow to call the new package. And repeat this every time you need to recompile the Package.


2. This solution works if you don't have option of bounce
          KILL ACTIVE/ERROR SESSIONS OF WORKFLOW

         DROP INVALID PACKAGE(Package for which your getting the error)

         RECOMPILE DROPPED PACKAGE

         FORCE RELOAD YOUR WORKFLOW IN DATABASE
3. Another trick that might work out is to cancel all the Active/Error instances of this Workflow by using the System Administrator>Workflow : Administrator Workflow>Status Monitor.
4. Depending upon your access to the Instance(Workflow Manager) you need to restart the Notification mailer and Service components. If this doesn't work out then you go for 4.
5. Get your DBA/Sysadmin to bounce the instance.

Oracle Notifications: How to Modify standard contend

Below are details from Workflow guide to Hide some standard buttons/content in the Notification mailer

#HIDE_MOREINFO Attribute

If you are using the Oracle Applications Framework-based version of the Worklist pages available with Oracle Workflow embedded in Oracle Applications, 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.

Note: In both the standalone version of Oracle Workflow and the Oracle Applications version of Oracle Workflow, the #HIDE_MOREINFO attribute also determines whether the Request Information response link is included or excluded in HTML-formatted e-mail notifications. However, note that if the #HIDE_MOREINFO attribute is not defined for a particular notification, the default behavior is different for the Notification Details page and for HTML-formatted e-mail notifications. The Notification Details page displays the Request Information button if the #HIDE_MOREINFO attribute is not defined, while an HTML-formatted e-mail notification will exclude the Request Information response link by default if the #HIDE_MOREINFO attribute is not defined. To control this option in all interfaces where users access notifications, you should explicitly define and set the #HIDE_MOREINFO attribute. See: To Respond to an HTML E-mail Notification, Oracle Workflow User's Guide

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.

Note: It is recommended to define the #HIDE_MOREINFO attribute with a type of lookup and assign it the predefined Yes/No lookup type that is provided in the Standard item type. The Yes/No lookup type contains two lookup codes with the display names Yes and No, representing the values Y and N, respectively.

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.

Note: The Oracle Workflow web pages are being converted to the Oracle Applications Framework user interface format. Depending on your version of Oracle Workflow and which patches you have applied, you may see Oracle Workflow web pages in the new format or in the previous format. The new Worklist pages that include the Request Information button are currently available for the version of Oracle Workflow embedded in Oracle Applications.


#HIDE_REASSIGN Attribute

You can use a special message attribute with the internal name #HIDE_REASSIGN to hide the Reassign button in the Notification Detail web page. When users view a notification from their Worklist web page, the response section in the Notification Detail 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.

Note: If you are using the Oracle Applications Framework-based version of the Worklist pages available with Oracle Workflow embedded in Oracle Applications, the Notification Detail page may include the Delegate button or the Transfer button instead of the Reassign button, depending on the setting of the FND: Notification Reassign Mode profile option. The #HIDE_REASSIGN attribute controls the Delegate button and the Transfer button in the same way as the Reassign button. See: Setting the FND: Notification Reassign Mode Profile Option, Oracle Workflow Administrator's Guide.

If you are using the Oracle Applications Framework-based version of the Worklist and home pages available with Oracle Workflow embedded in Oracle Applications, then 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.

The #HIDE_REASSIGN attribute must be either of type text or lookup. To hide the Reassign button in the Notification Detail page, and to prevent reassignment from the Advanced Worklist, Personal Worklist, and self-service home page, set the value of this attribute to Y. To display the Reassign button in the Notification Detail page, and to allow reassignment from the Advanced Worklist, Personal Worklist, and self-service home page, set the value to N.

Note: It is recommended to define the #HIDE_REASSIGN attribute with a type of lookup and assign it the predefined Yes/No lookup type that is provided in the Standard item type. The Yes/No lookup type contains two lookup codes with the display names Yes and No, representing the values Y and N, respectively.

Courtesy: Oracle Workflow guide