Question - Policy lifecycle: making a policy obsolete

Hello,
I have a question about the Security Policies module.
One of the built-in fields is ‘Status’, where you can chose either ‘Draft’ or ‘Published’.

To suit our documentation workflow, I would like to have a third option here, ‘Obsolete’.
This would be for when a policy is withdrawn or replaced by a different document (e.g. sometimes the contents of one policy is merged into another one).
At this point, the old policy is only for historical reference and it would no longer apply to staff, or need to be reviewed any more. (I guess we would set it to no longer appear in the eramba policy portal either)

I wouldn’t simply want to delete an obsolete policy from policy module, as we would want to keep in on file for future reference.

Is it possible to configure this kind thing?
By default, it seems it is mandatory for a policy to have a future review date, and the only way to stop that is to delete it altogether.

1 Like

Although - I do note that if you ‘delete’ a policy, you actually move it to the ‘Trash’, so you can still see it in Dashboard/Security Policies/Trash…

So I wondered if I could just regard policies in ‘Trash’ as ‘Obsolete’?
However that doesn’t really work, as you can’t read the content of policies in the Trash - you need to click History > Restore and resurrect them into the main Policies list… and then when you do, the attached PDF content is no longer there. :frowning:
And indeed, if I go to Edit to restored policy, and go to Policy Content > Document Content, that field seems to be greyed out now - I can’t re-add the old PDF. (Is that a bug?)

Hello David,

Welcome to our forum,
To your first question, right now it is not possible to configure the custom status of the policy.
@eramba needs to decide if it is something we want to implement.
To your second question - Yes, it looks like the content is not properly restored. But on new version it is already fixed so I will not create ani item.
Thanks for reporting.

Cheers for the reply!

Having some kind of ‘obsolete’ or ‘withdrawn’ status for a document is a fairly common workflow, so I guess that would be a handy for helping Eramba to fit with many users’ real-world documentation processes.
Although I can already see ways I can workaround it for my workplace - for instance, most users in my workplace with not be going into the Security Policies module, they will just consume polices by getting them from the Policy Portal web page - so I can simply set obsolete documents not to appear there, and I can use a label to filter them out of my own views in the Polices module.
I also have just tried setting their next review to be due a hundred years into the future, so we won’t be getting review notifications about them… slightly ‘untidy’ perhaps, but in practice just the same as if they had no upcoming review associated.

Just a further comment/query on how this works currently -
I tried importing a few of my old legacy documents into Eramba (so they are just in the system for read-only reference), and setting their mandatory ‘next review date’ to something a century into the future, so I will not be pestered with a notification or status for an overdue review for them.

When I go into the ‘Security Policy Reviews’ tab, there are initially two reviews for each of these old documents - one has the status ‘CURRENT’ the (system generated) Description ‘This review was created by the system at the time the policy was created - If you used “attachments” as content, then dont forget to attach policies to this review.
And then the second review listed for it is has the status ‘OK’, and the date I set (a century into the future).

That is all fine and makes sense to me, but I also noticed I am able to select ‘Actions > Delete’ on the second remove, and get rid of it!
I was not expecting this, since I was under the impression that all Security Policy items must have a scheduled review.
Is it OK to simply delete a Policy’s upcoming review, so it is left with no upcoming review attached to it? I won’t ‘break’ anything by doing this?

scratch that - even though I delete the second review listing, the 1-century-ahead review-due-date on it still stays on the parent Security Policy…

you do not need to do this, if you wont review your policies with eramba simply bulk delete incomplete review records and done , there wont be nothing incomplete for the future

I see.
I mean the large majority of documents in my Security Policies module will be getting an annual review.
It is just a few old ones which are ‘obsolete’ now and no longer need one.

I think what confused me a bit as well is that Eramba seems to live in the present tense, it did not really have a concept of me importing 7 years of old documents that were managed manually before we started using Eramba. The field ‘Actual review date’ seemed a bit counter-intuitive, because it seems to want to be ‘date you actually put this item into Eramba’ rather than ‘date the item was actually reviewed in real life’, and so it doesn’t let you put in dates from the past.