Identifying the last usage of a process model

As active Appian process instances are stored in memory, there isn't really anything in the primary data source you can query for usage globally.  If these processes are updating database values with timestamps, you could review them this way on a process by process basis.

However Process Reports are typically my go-to here for this type of initiative.  Is it not acceptable to utilize say counts of active processes, with pp!starttime, from those Process Reports?

Hi Chris,

thanks for your response.

Active processes can be found in the monitoring and in the process model reports, so, not a problem.

The problem for me is to identify if a process model (having not active instances at that particular moment) has been used recently or not.

In other words, knowing the last time an instance was created for a process model that currently has no active instances and no references in the health-check.

Gotcha.  While Process Reports can be run on completed processes as well, instances will only be available here while the timeframe is within the process archive setting, which differs per model.  Once instances are archived they will drop from the report.

Any data persisted to the DB with timestamps is also a typical target, but this will be on a process by process basis as well.  This is what we use to determine usage - as we configure all processes to record an audit row between any steps with timestamp, to easily keep an eye on what is moving and what is not.  

Depending on how long you retain Process Execution Logs, this could be a potential source also.

At the end of the day, a process model with no in-memory instances is not putting any stress on the server, it doesn't really provide any benefit to remove them.  We always retain all process models in the environment, just changing permissions where they will no longer be used.  If you want the feel of more organization, you could just remove from application bundles.

Is your goal for cleansing to reduce clutter in the user experience, or otherwise? 

Gotcha.  While Process Reports can be run on completed processes as well, instances will only be available here while the timeframe is within the process archive setting, which differs per model.  Once instances are archived they will drop from the report.

Any data persisted to the DB with timestamps is also a typical target, but this will be on a process by process basis as well.  This is what we use to determine usage - as we configure all processes to record an audit row between any steps with timestamp, to easily keep an eye on what is moving and what is not.  

Depending on how long you retain Process Execution Logs, this could be a potential source also.

At the end of the day, a process model with no in-memory instances is not putting any stress on the server, it doesn't really provide any benefit to remove them.  We always retain all process models in the environment, just changing permissions where they will no longer be used.  If you want the feel of more organization, you could just remove from application bundles.

Is your goal for cleansing to reduce clutter in the user experience, or otherwise? 

Thanks again Chris,

Process Execution Logs looked like a good direction, but the available content is limited to TOP values. There are top_processes_by_time and top_models_by_time, which means that models with low executions compared with others will not be shown.

It was a very good direction, but unfortunately content was limited to top.

I need this information for healthy cleaning (which is always good) and for impact analysis. We are having around 1000 process models and estimations are becoming tricky. 

Most of the code is valid and active, but we want to ensure that we are not considering dead code in the impacts.

Sure thing!  But, I will probably have to defer to other practitioners from here.  In our environment (1,641 process models), we do not (and likely will never) perform any cleanup as far as removing models or code, as inactive processes do not negatively affect the server.  The only cleanup we perform would be on process instances to ensure those are not orphaned, or have incorrect archive settings, spending memory resources unnecessarily.  

That makes sense.

I guess that after having a 9 years old appian project we need to take some additional considerations :)

In some situations, but it depends. Our environment is older as well, dating back to 2007.  Still have just a few Portal processes we're finalizing conversions of - been working that initiative since 2015 or so, along side new work :)

Aside from process instance cleanup, the only other real cleanup activities we perform are for removing/replacing deprecated plugins, old product customizations, and things of that nature.  But those long living process instances have been our primary server-stressor, which were required often in the Portal days.  We've been able to cut them down by about 80% or more since Portal, while adding new applications regularly. 

Otherwise, our server is plenty happy currently housing:

In-memory process instances: 250,000
Constants: 5,350
Data stores: 300
Data types: 900
Expression rules: 5,300
Groups: 1,700
Interfaces: 3,300
Process Models: 1,640
Records: 123
Reports: 900
Documents: 2.7 million
Tasks Completed: 6 million

Hi Chris,

Any inputs on Douments cleanup ( 80 k files ) , Portal based application, we have more KC douments 60 k+ . it is cosuming more diskspce around  1300 GB. We are storing all douments in appian. How to analysis on this further.

Thanks,

Sushma.

@sushma are you able to figure document cleanup process. I have similar requirement and I am curios on the findings.