Reported by @mspiep01 in #530

By default, new Log__c records are created by the Automated Process user and assigned to the User that generated the log (by setting Log__c.OwnerId = Log__c.LoggedBy__c). This causes an exception when the logging user (Log__c.LoggedBy__c) has a license type that can't own object records. Here are my initial findings - it seems like the autoproc user, a Chatter Free user, an Identity user, and others profiles will cause (and presumably have been causing) issues.

Bugfix considerations

When possible, I'd like to still assign the LoggedBy__c user as the OwnerId. Part of the original intent behind setting Log__c.OwnerId = Log__c.LoggedBy__c was to try to mitigate ownership data skew issues. It also helps in orgs that utilize the End User permission set - Log__c has a private sharing model, so end users will only see records that they have been granted access to view, which can be accomplished by assigning them as the record owner.

But when that's not possible, assigning a (new) default queue as the owner seems like the best option.

• This could still lead to ownership data skew issues (if a large number of Log__c records are assigned to the new queue), so some orgs may need to consider manually reassigning (or purging) Log__c records if needed. But using a queue would avoid the current issue that some users simply can't own their own records.
• Orgs can customize the queue members directly in their orgs - any changes to queue members made directly in orgs wouldn't be impacted by future upgrades to Nebula Logger
• The queue should include all of Nebula Logger's custom objects. For now, only Log__c records will be automatically assigned to the queue, but since there's going to be a queue anyway, might as well make it work for all of the objects in the data model.
• The name of the queue used within Nebula Logger's code should be configurable via LoggerParameter__mdt, in case any orgs want to use a different queue