First thing is if a task has been attached with an adapter then this adapter will run when the task achieves pending status(P). Now there are some rules for doing things the way you want:

(1) If a task(conditional etc) has "Disable" effect set then whenever you disable the user, the engine will look for all tasks which have disable affect set and will try to insert them. And adapters attached to the task inserted will run whenever these tasks go to "P" status.

(2)If a task(conditional etc) has "Enable" effect set then whenever you enable the user, the engine will look for all tasks with enable affect and will try to insert them. And adapters attached to the task inserted will run whenever these tasks go to "P" status.

(3)If you want to run a task based on the update of a field on the process form/system forms then you need to define that task(condition, allow multiple) as "Field-Name Updated" or "Change Field-Name" depending upon whether it is a pre-packaged integration/process form or system forms (please see details below):

Pre-packaged integrations contain Process Form tasks, per naming schema specified below ("<Field label> Updated").

For User/Organization form the specific tasks need to be defined using the predefined task names contained in lkv table. Password propagation was not completely operational in initial Mercury builds but was fixed (Bug 588) in later 7.2 builds and it is definitely available in 7.2 GA Build 1022. No changes were done to this functionality since. Please use the following sql to verify task names (lkv_decoded) and corresponding column names (lkv_encoded) for your installation:

SQL> select substr(lkv.lkv_encoded,1,25) lkv_encoded,

2 substr(lkv.lkv_decoded,1,25) lkv_decoded from lkv

3 where lkv.lku_key = (select lku.lku_key from lku

4 where

lku_type_string_key='Lookup.USR_PROCESS_TRIGGERS');

LKV_ENCODED LKV_DECODED

------------------------- -------------------------

USR_LOCATION Change User Location

ACT_KEY Move User

USR_EMP_TYPE Change User Type

USR_PASSWORD Change User Password

USR_MANAGER Change User Manager

USR_LOGIN Change Username

USR_FIRST_NAME Change First Name

USR_LAST_NAME Change Last Name

USR_TYPE Change User Identity

9 rows selected.

SQL> select substr(lkv.lkv_encoded,1,25) lkv_encoded,

2 substr(lkv.lkv_decoded,1,25) lkv_decoded from lkv

3 where lkv.lku_key = (select lku.lku_key from lku

4 where

lku_type_string_key='Lookup.ACT_PROCESS_TRIGGERS');

LKV_ENCODED LKV_DECODED

------------------------- -------------------------

ACT_CUST_TYPE Change Organization Type

ACT_NAME Change Organization Name

PARENT_KEY Move Organization

(4) If you delete a user in xellerate then it tries to cancel all provisioned instances of resource object for this user. Now you can add a task(let suppose "Delete User" which will try to run an adapter to delete a user in target) which you want to be inserted when a xellerate user is deleted as "Undo" task for "Create User" task. As all provisioned instances are cancelled which will cancel their tasks and when "create user" task is cancelled it will insert its "undo" task.

This is undo functionality.

(5) There are also "tasks to be generated" option on the "edit task window" and that is used to generate/insert tasks based on the response code. Let suppose you want to run task t1 based on the "true" response of the adapter attached to task t2, then you can assign task t1 as "task to be generated" for "true" response for task t2.