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!

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.

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!

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.

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!

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,

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.

Original Message:
Sent: 07-27-2023 13:55
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?

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
------------------------------

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.

Original Message:
Sent: 07-27-2023 13:55
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?

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
------------------------------