How to make an account active or inactive?

Hi Braedon,

Basing automation off date modified could also result in false positives since there are times the account record is updated (e.g. changing assigned user, an integration pushing some data into the record, etc.) that don't signify meaningful activity. 

Can you elaborate more on your use case? What is the purpose of the active/inactive designation and are there specific correlating events that trigger a status change or ensure an account remains in either status?

Braedon Owen - These aren't exactly what you're looking for, but I'd recommend reviewing these articles as they cover similar use cases that may help provide the building blocks to configure this process best for your organization:

• Capturing a Record's Last Activity Date Using Workflows  
• Capturing Records' Activity Counts Using Calculated Fields 
• Reporting on Records With No Activities 

There are a variety of ways to track account activity and using your preferred tracking method, you can build the necessary field(s).

Hope this helps!

Hi Chris,

Thanks for the feedback.

The purpose would be to notify an account manager that there has been no activity on said record for 'x' amount of time. So no activity I would probably specify as no action to the account or any related records (new or update). 

If there is a better/alternative way of doing this I am definitely open to suggestions

Thanks for the additional detail. My first though on how this could be achieved would be to create custom date or datetime field in the Accounts module. Once that field is created, you would then create separate processes to achieve the following use cases in SugarBPM:

1. Analyze the date field when it is updated and set the account to an inactive status if it remains unchanged for X days/weeks.
2. Update the date field in the account record and set the status to active for any qualifying update to the direct account record. (e.g. phone number is updated, account type value changed, etc.)
3. For each related module you classify as meaningful activity, a process that updates the parent account's date and sets the status to active based on the qualifying update in the child record. (e.g. opportunity sales stage changes, call record created, etc.)

If you have a lot of related modules or a lot of related records within certain modules, I recommend this solution over using Sugar Logic formulas. Sugar Logic can create performance bottlenecks if a large number of calculations have to be performed against related modules.

Ok this actually sounds like a good solution. I guess I have one more question here; is that custom date/datetime field going to have the 'calculated' box checked in studio? Or is this what you were talking about avoiding and SugarBPM will be doing all of the updating and calculating?

Edit 1: Also, where would I create these processes? I took a quick look at process definitions and process business rules however it doesn't seem that I can create a process to trigger and update the date field. 

Should this be run on a scheduler?

The date field should not be set as a calculated value as the only updates to that field should be done by the running processes. When designing the process definition, the action should set the date/datetime field to a value of 'Run Time' by clicking the 'Run Time' button immediately below the field:

The only scheduler dependency will be the stock SugarBPM scheduler as that will need to evaluate accounts that are potentially inactive.

Hi Chris,

Thank you for being so helpful. I've created all of the workflow's via workflow manage to determine when the last activity date field is updated. Now when I'm creating the process definition I'm a little lost. 

I'm not exactly sure how to design it. I have two start events (new and all updates with no criteria) that flow into one action (last activity date: runtime). 

Where/how do I have a checkbox get updated to true/false?

You can disregard this message, I've figured it out!

Thanks!

Hi Alex, those articles were very helpful. The 'Capturing a Record's Last Activity Date Using Workflows' article shows to use legacy 'Workflow Definitions'. Is that the best way to do what I am trying to? It appears that Chris is saying that may possibly create a bottleneck