One of the primary purposes of Strivr is to provide our clients with a full Audit Trail, consisting of a detailed history of all their processes.

The aim has always been to assist with compliance regulations and create a reliable source of historical actions.

Default configuration

As per our current default, itโ€™s not been possible to change the status of a subprocess that has passed its active interval (Daily subprocess is only available for changing Today and in the future, Weekly subprocess - this week, Monthly - this month, etc.).

Custom expiration term

We can now allow softer subprocess lockdown rules to let a User change the status of a subprocess for an extended period โ€“ meaning you can now change the status of a process for longer than usual.

For example, before this update, you couldnโ€™t amend a subprocess after it had expired (if it was a daily process, it would lock after a day โ€“ weekly process after a week and so on). Well, we can change this now! ๐Ÿ‹๐Ÿผโ€โ™‚๏ธ If you would like us to configure this setting for your organisation please contact us and we can set up the new rules. Obs. These apply to all the processes according to the rules you set.

๐Ÿ“ŒNote:

  • Configuration can only be changed by the Support team at Strivr, shoot us an e-mail at [email protected] ๐Ÿ“ง

  • Provide us with a number of calendar days to extend the deadline term with (consider the optimal number of days, including weekends and holidays)

  • If it is not set, it will use the default configuration according to subprocess frequency

  • Expiration cannot be applied to Once frequency processes since you can always change their status

Example

Service Provider organization has a custom expiration term set for processes that occur on a monthly basis & their users are allowed to change the status up to 60 calendar days backwards.

โช 60 days from today (2022-01-25) is Thursday, 26 November 2021.

Dashboard view

Even though itโ€™s 2022-01-25 today, users in Service Provider organization can still make changes on the previous month's deadlines, while subprocesses from November are locked:

Did this answer your question?