Create a Task to Follow-up on a Call without losing the Call to Contact or Account connection

Hi Bud Hartley ,

There is no direct way to create sibling records in SugarBPM. The best way I can think to achieve this use case is to do the following:

1. Create fields on the account module for the fields from your Calls module that you want to carry over to the follow up task (e.g. Call Name, Task Due Date, Task Details)
2. Have a process configured so that when a call is completed, it updates those fields on the parent account
3. Have a second process on the accounts module that triggers when any one of those fields change, that it then creates a related task

Chris

Thanks Chris Raffle !

That might actually work!  I will give it a try and let you know if it works for me.

I'll probably hide the fields in the Contact Record so it doesn't add any confusion, and remove the information from the Contact Record after the Task is created.

THANKS for the suggestion!

Hi Bud Hartley 

Hope you don't mind me asking, but I wasn't clear, do you actually need a followup Task or Call?

I wasn't sure if the Task was to remind a user to have a followup Call

Bud Hartley said:

task name is set as "Call Follow-Up

Hi Tony Romano ,

The request was from one of the Sales Managers.  His Team is not making good use of the Tasks Module and he wanted to simplify the process of them setting a Task to Follow-Up on a Call they recorded.

Instead of creating a new task related to a Contact or an Account, he asked me to code a better way.  Knowing that I could create a new record in BPM, I started with a checkbox in the Call Record that revealed two fields to be populated.  When the call was saved, the new Task was created.  The issue was that the Call was Flex Related to the Task and the relationship to the Contact or Account was lost.

Chris Raffle  suggested an approach that I'll be trying this week - I think it will do what I need.

SUCCESS!  Thanks Chris Raffle !

Wow, It works!  Thanks for the insight.

FYI: Because of the Flex Relate field, I had to add fields to both the Accounts and Contacts Modules (I may have to add them to other modules, but Calls aren't normally attached to them).

The process to copy the fields from the Calls Module to the Account and Contact is a parallel path.  The individual Task Creation processes has a final step of erasing the fields that were copied from the call.

Thanks again for the insight of an approach to do this Chris.  I appreciate your help!

Impressive workaround to get this done without code.

I personally have not tried BPM yet, but if things get so complicated, maybe, in cases like this one, a custom logic hook would be a bit cleaner without all the extra fields which, would all end up being just temporary and therefore empty columns in the table?

FrancescaS

I agree that a logic hook would be a cleaner approach if I were to solve this use case today. For customers who don't have developers on-hand or dedicated to the project, there is often a tradeoff of having a solution admins can directly maintain versus a developed solution that is more efficient but requires specialized resources. SugarBPM does a great job at satisfying the former and, with creativity, can accomplish a lot of solutions that would typically default to custom code.

The most important part of employing those 'creative' solutions is making sure the system is well-documented (e.g. using comment text on the fields in Studio, documenting changes at the process definition level and within the process canvas itself), so others (and sometimes the person who did it ) know what purposes those pointless-at-first-glance fields serve. 

Chris

Oh yes, the documentation is VERY important.  In addition to the Help and Comment Text for the fields I've been writing Comments in the Process and often Word Documents that document the document the thinking.  Thanks again Chris.  The Sales Manager is very happy with the result.

hi Bud Hartley 

Ah OK, understood.

I've done this previously by creating a one-2-many relationship between Calls and Tasks module.

I chose this approach because the Task stays related to the Call.