PA: Notification email sends old info

Hi KGM,

Thank you for showing the Process and where the record is reassigned in the process. That is helpful.

In the screenshot, the action you have circled appears (assuming from labels) to reassign the Campaign record to the current owner of the Campaign record. This sounds like it makes no change at all, based on the description of 'current owner in SugarCRM's documentation:

"Record Owner : The Record Owner is the user who is in the Assigned To field of the targeted Sugar record."

Double check to be 100% sure the circled action is the action that is triggering the notification email.

If it is the action sending out the assignment notification, can you offer a brief explanation as to what it is doing that causes this to change the Assigned To from one value to another? Thanks!

Thanks for your answer Patrick.

If we take the "rejection route", the thought behind this is to get the approver´s "fingerprint" onto the records. That is why the first update is to change the status (which is also needed since the record was rejected). Next update is to document in the record who rejected it (I do that by updating the "Description" field with so we´ll know later who rejected:

The last update (Assign to record owner) is only to trigger the email notification so the record owner (one who created the record) knows his/her record was rejected. I was planning to use the built in email notification (the "assign" notification, you know each time a record is assigned, Sugar sends an email notification to the new assignee), and that works except the notification email contains old data. It does not contain the new, updated status (even though the record has the new "Rejected" status, etc).

So the issue is not who gets assigned but the content in the notifcation email. But maybe I am using this wrong (even though I manage to trigger the notifcation email)...

Does that make sense?

Yes, I am trying to label the updates/actions with what happens to be transparent.

Thanks

KGM

Hi KGM,

I might be doing something wrong, but in an instance where I the assignment notifications are working for manual changes, I can't get the process to trigger a notification when I reassign a Campaign record, so I am unable at this time to test or confirm what you describe.

Is there is a use case for not creating a Process Email Template and sending that to the Campaign owner with the field info you wish to share?

Hi again.

Well, uhh, no there is no real reason why I don´t use a Process Email Template. The other notification just came automatically so I used it. But...   Now I´ve changed the process:

I took out that reassignment yet the default "assign" notification email comes. So I am guess that the "Supervisor Approval" activity is triggering it (which makes sense that the email does not have update info because the email is sent BEFORE the process gets to the two update actions). Btw, these two update action DO NOT re-assign.

In other words, after I changed the process to the picture above and I go the blue arrow route, I get 2 emails! One from the "Send Rejection Notification" action and the other one (the reason for this question in the first place) comes automatically.

This is what is happening at the "Supervisor Approval" action:

If we look at the history (above, the supervisor has not yet approved and notification is not yet sent), then PA is assigned the record, it seems in the background. Could it be that when the supervisor has approved/rejected, then the record is re-assigned by the PA to the one who created it, thereby triggering the "default assign notification email"?

And actually, now that I have a Email Template that I am using I´d like to turn off that "default assign notification email"  because there is no need for 2 notifications

I totally might be doing something wrong and triggering it by mistake. Thanks again

KGM

Patrick McQueen - hi, any update on this? 

Thanks,

KGM

I am happy I was able to help you confirm that it was not the specific element in this process causing the assignment alert.

In my testing of the approval process, and in my review of the documentation on it, I have been unable to reproduce or find any indication that the approval is the source of the reassignment.

Are you sure you do not have any other processes, workflows or custom automations that could be triggering a reassignment of this record momentarily to a different user?

Hi again

I only have one Campaign process, this one.

There are two reassignments in it (both to Marketing, later in the process - besides, I´ve been testing going the rejected route anyways so the process doesnt even go through these two reassignments):

I thought maybe this "assignment" in the Activity was the trigger to this "extra" notification email:

Because in the Process History, there is mention of "assigned" and "still assigned":

So I thought maybe the PA assigns the record temporarily to the boss and in reassigning back to the user who created the record, this "extra" notification was triggered.  Especially since the notification states that the Boss has assigned it to Tinni (the one who created the record):

But you have confirmed that is not the case. Hmmm, well maybe this is a localized problem - a PEBKAC    I must be overlooking/not seeing something.

Well thanks for your time and effort though.

KGM

Patrick McQueen sorry for spamming you but I tried something different (which I feel proofs my point). Instead of rejecting the record, I sent it to a new process user:

When that new process owner "Routed" the record back, the old default assignment notification (Sugar one) was triggered and, like I´ve mentioned above, sent to the person creating the record.

So, I really do think that it is the Activity box that is triggering this default assignment notification, no?

Thanks for your help

KGM

Hi Kristjan Geir Mathiesen,

With the newly stated goal to prove that the Activity box is the cause of the assignment notification in your instance, the next recommended diagnostic steps I would try are:

1. Create a new mutually exclusive Process Definition with only a start event, activity, gateway and end event.

2. Disable all other Processes and set all (if any) legacy workflows to inactive.

3. Navigate to Admin > System Settings, and set the error log to Info

4. Click View Log in Admin > System Settings to open the error log in a new tab and click Mark Point.

5. Navigate through the steps of the process (acknowledge the assignment notification was sent consistent with findings so far)

6. View the resulting Info-level errors which will include the queries.

7. Search for evidence the record was reassigned

If the notification is not sent with this stripped down process, then reactivate the process that is triggering it, activate it again, and do the same as above with the error log to identify the query reassigning your record.

Let me know how it goes. I'm happy to help how I can.

Hey champ!

I think I managed to do all that you listed up but ofcourse I´m not very skilled in reading the log... 

Did the the email notification. However, in line 24627 of my log we have:

act_send_notification, act_assignment_method, act_assign_team, act_assign_user, act_value_based_assignment, act_reassign,

And that too me seems like a notification sending "act". Yes?

Here is where this line is:

pmse_bpm_activity_definition.name,

                pmse_bpmn_activity.date_modified, pmse_bpmn_activity.modified_user_id, pmse_bpmn_activity.created_by,

                pmse_bpmn_activity.description, pmse_bpmn_activity.deleted, pmse_bpmn_activity.assigned_user_id, act_uid prj_id,

                pmse_bpm_activity_definition.pro_id, pmse_bpm_activity_definition.act_type, act_is_for_compensation, act_start_quantity,

                act_completion_quantity, act_task_type, act_implementation, act_instantiate, act_script_type, act_script,

                act_loop_type, act_test_before, act_loop_maximum, act_loop_condition, act_loop_cardinality, act_loop_behavior,

                act_is_adhoc, act_is_collapsed, act_completion_condition, act_ordering, act_cancel_remaining_instances, act_protocol,

                act_method, act_is_global, act_referer, act_default_flow, act_master_diagram, act_duration, act_duration_unit,

                act_send_notification, act_assignment_method, act_assign_team, act_assign_user, act_value_based_assignment, act_reassign,

                act_reassign_team, act_adhoc, act_adhoc_behavior,act_adhoc_team, act_response_buttons,act_last_user_assigned,

                act_field_module,act_fields,act_readonly_fields,act_expected_time,act_required_fields, act_related_modules,

                act_service_url,act_service_params,act_service_method,act_update_record_owner,execution_mode

Do you want the log?

Thanks,

KGM