• Design Time permissions — Control which User Groups and Users can create, read, update, and delete entities.

• Runtime permissions — Control which User Groups and Users can access data, execute services, and trigger events on a Thing, including Data Tables, Streams, and Users. You can set runtime permissions at a Thing, Thing Template, or entities collection level. The abstract entities, Thing Shapes, Data Shapes, and User Groups in the model, do not have runtime permissions.

• Visibility permissions — Define which Organization and organization units have access to view an entity. If the members of an Organization or organizational units do not have visibility access, they cannot view the entity in the entity list or search results. They also cannot be assigned read, write, subscribe, and other permissions within visibility rights.

• Users who are meant to see all audit entries, in the same way as an Administrator can, should be added to the user group created by following the steps outlined in the section below, Required Permissions for a Non-Admin to Run Audit Services.

• Users who are meant to see all audit entries associated with a particular Thing should be added to the Auditors user group and given runtime permissions to the QueryAuditHistory service on the Thing as well as visibility and runtime permissions on the Thing.

• Users who are meant to see only audit entries within their user context should be given runtime permissions to the QueryAuditHistory service on the Thing as well as runtime permissions and visibility to the Thing.

• Audit subsystem, which is a system object that exposes the following services in both implementations:

◦ Service Execute — QueryAuditHistory run against the audit subsystem

◦ Service Execute — ArchiveAuditHistory

◦ Service Execute — ExportAuditData

◦ Service Execute — CleanupOfflineAudit

◦ Service Execute — GetAuditEntryCount

◦ Service Execute — PurgeAuditData

◦ Service Execute — ExportOnlineAuditData

◦ Service Execute — ArchiveAuditHistoryDirectPersistence

◦ Service Execute — QueryAuditHistoryWithQueryCriteria

◦ Service Execute — QueryAuditHistoryrun against a Thing

• AuditArchiveFileRepository, which is the file repository of the audit subsystem that is used for the audit archives. Created on startup of the subsystem, the repository has a directory for the currently active implementation. If you switch from one implementation to the other, the audit data from the previously active implementation is preserved and a new directory for the currently active implementation is created. The structure of the repository looks similar to the following in an installation where both implementations have been active:

• Depending on the active implementation, one of two schedulers for archiving audit data:

◦ AuditArchiveScheduler, which is a Scheduler Thing that controls the automated archiving of audit entries for the Data Table implementation.

◦ AuditArchiveSchedulerDirectPersistence, which is a Scheduler Thing that controls the automated archiving of audit entries for the Direct Persistence implementation.

• AuditPurgeScheduler, which is a Scheduler thing that controls the automated purging of online audit entries.

• AuditArchiveCleanupScheduler, which schedules the clean-up of offline, archived audit data files.

• AuditArchiveCleanupNotificationScheduler, which sends reminder notifications of the clean-up.

• Audit Subsystem — Visibility permissions

• Audit Subsystem — Design time permissions — allow read

• Audit Subsystem Runtime permissions — Define a service override for each service that you want users in the group to be able to invoke, and allow Service Execute.