Clarity

Answer 1: On Project Create you may have a required field that could potentially change throughout the life of a project and have a process fire based on that field. Since it's required, it will be initialized when the project is created, and if the field ever changes the process will fire again for the update.

For example, a process could automatically add a resource listed as the project manager to the project team. The initial manager was set when the project was created (especially if manager was a required field). But if the project manager changes sometime in the project’s lifecycle, the new manager will be added to the team via the update process. Only one process is needed because Create and Update will handle both start conditions.

Answer 2: Suppose you want an update to happen based on a Boolean field. The update to another object is the same in both scenarios, but if the Boolean field is never checked, it shouldn't start. In this case an Update process would be developed, but if that field is on the Create screen, we could check the Boolean field on Create, so a second process that just calls the first is created, and there's no duplicate code.

Another scenario: after an Idea is created, a process needs to trigger when a status is submitted. This can happen at the creation of the Idea by selecting Submit for Approval or some time later. The same steps apply in either case, and the two processes are required to maintain continuity.

Answer 3: You can also relate this to the Work Request notifications. Many people are using two separate processes to send the notifications (one for when the initial object is created and the other for status updates). This new feature would allow you to send the same notification with a single process.

Answer 4: We think the big advantage of this combined process is streamlining. It could reduce development and maintenance cost, as well as solve the problem of one process undergoing an update when another is forgotten.

A few other things we've noticed, you might consider:

1. We cannot trigger a process for changes on Multi-select attributes. (New Multi-select value != Old Multi-select value)

2. XOG Errors are not easy to interpret. Sometimes we get SUCCESS as XOG states, although the process may fail inserting/updating.

3. The UI does not refresh automatically when the process finishes. This is a small but very noticeable issue.

The query below pulls users and their user status, as long as they're assigned to a security group defined by a parameter in the query.

Feel free to modify this based on your needs, and let us know if you need additional information.

SELECT res.full_name, cap.name, u.user_status_id

FROM cmn_sec_user_groups grp, srm_resources res, cmn_sec_users u,

(SELECT id, group_code FROM cmn_sec_groups

WHERE is_active = 1

AND group_role_type = 'GROUP') group_list,

(SELECT * FROM cmn_captions_nls

WHERE table_name = 'CMN_SEC_GROUPS'

AND language_code = 'en') cap

WHERE group_list.id = grp.group_id

AND res.user_id = grp.user_id

AND cap.pk_id = group_list.id

and res.user_id = u.id;

Answer 1: This issue is usually linked to the job Update Estimates from Allocation, which requires that the project/NPIO have an Effort task – id  = ~rmw. If there is no effort task on the Project, it probably won’t display in the list. It would make sense for it to be absent, since normally, on NPIOs, we don’t get to see the Task tab and therefore can’t set the ETCs directly. Try testing it.

Answer 2:  This action will only show up on projects which have a single effort task (~rmw). If the project has a complete WBS structure with many task assignments, this job will not be available, as the job would not know how to perform the split.