Hi John!
Thanks for the post.
TL/DR;
You can configure notification which are simple text instead of HTML and without attachments. These notifications will not generate items into the Distribution Temporary Cache and further will not require access to the location.
Expanded Answer;
The Distribution Temporary Cache is used in a number of scenarios. In general, it is used to provide advanced features of notifications and will continued to be used in the future as more features are available across the system for notifications.
Currently (as of OnBase 16), it is required for the following cases:
- Using Distribution Service via the Thick Client with emails that have attachments (including classic Workflow and Document Distribution with the global client setting)
- Using formatted notifications
- WorkView messages with a body that would be > 64,000 bytes
If a system is only using Core-based Workflow with plain text notifications, then the Distribution Temporary Cache is not required since none of the files will be generated at notification creation.
The Distribution Temporary Cache acts almost like a transient Disk Group. The writers are going to be any process that initiates sending of one of these notifications:
- Thick Client/Configuration
- Application Server
- Workflow Timer Service / Unity Scheduler
- Any other process that can generate a notification
The reader will always be the Hyland Distribution Service. This means the account running the Hyland Distribution Service will require read access to the location. Any process which is writing to the location will need access to create the notification.
In the case of everything being processed through the Core (ie users are using the Web or Unity Client, not the OnBase Thick Client), only the Core-based processes (the Application Server, Workflow Timer Service/Unity Scheduler, etc) would need access to the location. However in the case of user created notifications generated from the OnBase Thick Client, all users would need access to the location. Investigation into the way which notifications are generated in the system would need to occur to determine which processes are generating the notifications and how it could be locked down to the users running the process (ie Application Server identity account or the account running the Unity Scheduler process) instead of all users have access.
Take care.
