Precisely Enterworks

Hello,

We have an attribute called Record Status where admins and users can set the record as Deleted for a 'soft delete'.  Meaning other downstream systems will no longer use that record, but it will not be completely removed from the system.  There are times a record is no longer needed, but it's possible that it could eventually be needed again.  Also, with our other systems, we 'soft delete' to avoid issues downstream in those systems that a hard delete can cause.  But then we have all of these soft deleted records that have to be manually filtered out each time and just clutter stuff up.

This may be a terrible idea...I'm open to anything...but we were thinking it would be nice if we could have the system automatically move those records, once set as Record Status Deleted, to a new Deleted repo.  This would get them out of the way from normal day-to-day work and allow us to safely hard delete them after it has been confirmed that it is safe to do so.  It would also allow us to easily un-delete them as needed...once the Record Status is cleared in the Deleted repo, the record is then automatically moved back to its parent repo.  Ideally, moving all of the record history with it each time would be amazing and really helpful as well.  We have a handful of repositories that would all need a new corresponding Deleted repo to go with it.

I assume this would require the new Deleted repos to have all of the same attributes as their parent repos so that when the record is set as Record Status Deleted, a change notification (or something) could then move the entire record and its data to its respective Deleted repo.  I also assume having to manually keep those repos in sync could be a pain to manage any time a new attribute is added or updated unless the two repos could stay in sync automatically...the child Deleted repo would automatically sync attributes and repo changes from its parent repo.  Kind of like how Staging and Production work.

Is this possible?  Or is there a better way?

Thanks!

------------------------------
Ryan Hayes
Sundance Catalog Co
UT
------------------------------

Hello Ryan,

If the goal is merely to hide the records from regular users, then a Record Security Filter might be a simpler/safer option.

And then applying this filter to all groups except the Administrator (or any additional business Admin groups you may have) would hide those records from them. Flipping the flag back would make them reappear in the repository.

------------------------------
Technical Practice Lead | Enterworks Practice
Amplifi Inc. | www.goamplifi.com
Based in Scottsdale,AZ, USA
------------------------------

Hey Matthew,

Thanks for the reply!  We aren't necessarily wanting to hide the record from the users, rather we just want to put it somewhere else out of the way until it needs to be un-deleted or safely hard deleted.  We would still want users to be able to find and un-delete records as needed.  But this may be a good first step to try out and definitely a lot less involved.  It may not be ideal but may work well enough and we can just have a process to contact an admin to un-delete as needed.

Thanks!

------------------------------
Ryan Hayes
Sundance Catalog Co
UT
------------------------------

Original Message:
Sent: 07-27-2023 14:06
From: Matthew Hounslow
Subject: How can I create a child repo and keep its attributes and properties in sync with the parent repo and auto move records to the child repo based on an attributes value?

Hello Ryan,

If the goal is merely to hide the records from regular users, then a Record Security Filter might be a simpler/safer option.

And then applying this filter to all groups except the Administrator (or any additional business Admin groups you may have) would hide those records from them. Flipping the flag back would make them reappear in the repository.

------------------------------
Technical Practice Lead | Enterworks Practice
Amplifi Inc. | www.goamplifi.com
Based in Scottsdale,AZ, USA
------------------------------

Matthew,

Using Record Security Filters is a good idea and would be the simplest way to accomplish the desired core requirements, but may not be an option if Record Security Filters are already being used in the same repository for other purposes.  However, I think the opposite filter would be needed to hide the deleted records (your example would only show the deleted ones).  Perhaps the attribute would have the Yes No code set with the default set to No and then the Record Security Filter would have that attribute with Exact Match on No. Including the attribute in the snapshot table and then using the = (or <>) operator with an index applied to the attribute may provide better performance.

Having the Product support this capability is a good idea and using the Record Security Filter would be a good interim solution until such a capability was added.

------------------------------
Brian Zupke
Precisely Software Inc.
------------------------------

Original Message:
Sent: 07-27-2023 14:06
From: Matthew Hounslow
Subject: How can I create a child repo and keep its attributes and properties in sync with the parent repo and auto move records to the child repo based on an attributes value?

Hello Ryan,

If the goal is merely to hide the records from regular users, then a Record Security Filter might be a simpler/safer option.

And then applying this filter to all groups except the Administrator (or any additional business Admin groups you may have) would hide those records from them. Flipping the flag back would make them reappear in the repository.

------------------------------
Technical Practice Lead | Enterworks Practice
Amplifi Inc. | www.goamplifi.com
Based in Scottsdale,AZ, USA
------------------------------

Ryan,

If you weren't concerned about the history, a simple workflow could be constructed that soft-deletes the selected record by copying it to the delete repository (which would be using the same profile) and then delete the record from the original repository.  The undelete action would be a simple workflow on the delete repository which does the reverse.  But as you had already surmised, this loses the original history of the record (it is still in the history table, but only accessible through the Audit history option or SQL queries.

The solution proposed by Matthew to use a Record Security Filter would retain the filter, but might have performance consequences down the road.

It may be that performing literally what you had proposed might not be that difficult to do.  There are only to EnterWorks tables that would be involved.  Transferring a record (and it's history) from one repository to another may only require an update to the associated records in those two tables.  Transferring it back would be restoring the original values.  Such an action would necessitate that both repositories use the same profile definition, which would be desirable anyway.

I think having this capability be officially supported in the EnterWorks product has general applicability and from what I can see, would not require a significant amount of effort to provide.  You may want to consider submitting the idea on the Precisely Ideas web site (https://ideas.precisely.com).  The ideas can be up-voted by others so it would be advantageous to identify other use-cases than the one you describe here.  Presumably, the more popular the idea, the greater chance that it be accepted in a future release.

------------------------------
Brian Zupke
Precisely Software Inc.
------------------------------

Thanks, Brian!  I appreciate the response.  I have added this to the Ideas Portal as well, but it seems like that's where ideas go to die.  There isn't much action over there on the Enterworks side of things.  How many votes does it take to get a response from Precisely on whether the idea will be considered?

In the meantime, we may look into the workflow idea and discuss if losing the history in the UI...knowing that we can still query it in SQL if needed...is a dealbreaker.  Which I think may be.    

Thanks for the feedback and quick response!

------------------------------
Ryan Hayes
Sundance Catalog Co
UT
------------------------------

Original Message:
Sent: 07-28-2023 03:05
From: Brian Zupke
Subject: How can I create a child repo and keep its attributes and properties in sync with the parent repo and auto move records to the child repo based on an attributes value?

Ryan,

If you weren't concerned about the history, a simple workflow could be constructed that soft-deletes the selected record by copying it to the delete repository (which would be using the same profile) and then delete the record from the original repository.  The undelete action would be a simple workflow on the delete repository which does the reverse.  But as you had already surmised, this loses the original history of the record (it is still in the history table, but only accessible through the Audit history option or SQL queries.

The solution proposed by Matthew to use a Record Security Filter would retain the filter, but might have performance consequences down the road.

It may be that performing literally what you had proposed might not be that difficult to do.  There are only to EnterWorks tables that would be involved.  Transferring a record (and it's history) from one repository to another may only require an update to the associated records in those two tables.  Transferring it back would be restoring the original values.  Such an action would necessitate that both repositories use the same profile definition, which would be desirable anyway.

I think having this capability be officially supported in the EnterWorks product has general applicability and from what I can see, would not require a significant amount of effort to provide.  You may want to consider submitting the idea on the Precisely Ideas web site (https://ideas.precisely.com).  The ideas can be up-voted by others so it would be advantageous to identify other use-cases than the one you describe here.  Presumably, the more popular the idea, the greater chance that it be accepted in a future release.

------------------------------
Brian Zupke
Precisely Software Inc.
------------------------------

Ryan,

One thing to keep in mind is that the use of the Precisely Ideas web site for EnterWorks has only officially started recently with the earlier posts being made before that official start in the sense that Customer Support being notified of it being active.  It is only now that Customer Support is directing customers to submit improvement requests to that site vs. opening support tickets.

------------------------------
Brian Zupke
Precisely Software Inc.
------------------------------

Original Message:
Sent: 07-28-2023 12:27
From: Ryan Hayes
Subject: How can I create a child repo and keep its attributes and properties in sync with the parent repo and auto move records to the child repo based on an attributes value?

Thanks, Brian!  I appreciate the response.  I have added this to the Ideas Portal as well, but it seems like that's where ideas go to die.  There isn't much action over there on the Enterworks side of things.  How many votes does it take to get a response from Precisely on whether the idea will be considered?

In the meantime, we may look into the workflow idea and discuss if losing the history in the UI...knowing that we can still query it in SQL if needed...is a dealbreaker.  Which I think may be.    

Thanks for the feedback and quick response!

------------------------------
Ryan Hayes
Sundance Catalog Co
UT
------------------------------


Original Message:
Sent: 07-28-2023 03:05
From: Brian Zupke
Subject: How can I create a child repo and keep its attributes and properties in sync with the parent repo and auto move records to the child repo based on an attributes value?

Ryan,

If you weren't concerned about the history, a simple workflow could be constructed that soft-deletes the selected record by copying it to the delete repository (which would be using the same profile) and then delete the record from the original repository.  The undelete action would be a simple workflow on the delete repository which does the reverse.  But as you had already surmised, this loses the original history of the record (it is still in the history table, but only accessible through the Audit history option or SQL queries.

The solution proposed by Matthew to use a Record Security Filter would retain the filter, but might have performance consequences down the road.

It may be that performing literally what you had proposed might not be that difficult to do.  There are only to EnterWorks tables that would be involved.  Transferring a record (and it's history) from one repository to another may only require an update to the associated records in those two tables.  Transferring it back would be restoring the original values.  Such an action would necessitate that both repositories use the same profile definition, which would be desirable anyway.

I think having this capability be officially supported in the EnterWorks product has general applicability and from what I can see, would not require a significant amount of effort to provide.  You may want to consider submitting the idea on the Precisely Ideas web site (https://ideas.precisely.com).  The ideas can be up-voted by others so it would be advantageous to identify other use-cases than the one you describe here.  Presumably, the more popular the idea, the greater chance that it be accepted in a future release.

------------------------------
Brian Zupke
Precisely Software Inc.