Saw this great question in the Developers forum https://community.ptc.com/t5/ThingWorx-Developers/Thingworx-Permission-Hierarchy/m-p/556829#M29312. Answered it there, copying it to here:
I have a few of questions regarding the permissions model in Thingworx. I can't find any documentation that explains it clearly. Hoping someone can help, or point me in the right direction for more in depth documentation.
My understanding is that permissions can be set at a number of different levels.
Thanks in advance for any replies
Thing/Entity level permissions always take precedence
So if you set on Collection then on Template then on Entity it will first look at Entity then fill in with Template and Permission
So if Collection says can't do Service Execute
Template says Can execute Service 1 but not Service 2
Entity says Can execute Service 2 and leaves Service 1 as inherited
the end result is that the user can execute service 1 and 2
In Template and Entity you can find the Override ability, that is to specifically allow or disallow the execution of a Service or read/write of a Property
What is a BEST PRACTICE?
1. Give the System user all service execute on collection level
2. Give User Groups 'blanket' permissions to Property Read/Write on ThingTemplate Level
3. Give User Groups only Override permission to execute Services on ThingTemplate Level
4. Override User Group permission to DENY property read on potential properties they are not supposed to read on the ThingTemplate Level
Generally most properties all users can access fully and the blanket permission on a ThingTemplate is fine
It is very BAD to give user groups blanket permission to Service execute and should always be done by Override
Entity Hierarchy overrides the Allow Deny hierarchy, but within a single level (Collection / Template / Entity) Deny wins over Allow.
Create is indeed only set on the Collection Level, however the way to secure this is to give the System user the Create ability and create Wrapper services that use the CreateThing service which you can then secure for specific Groups. So you could create a CreateNewThingType1 and CreateNewThingType2 for example and give User Group 1 permission to Type 1 creation and User Group 2 permission to Type 2 creation.
Hope that helps.
What are your thoughts on Runtime Event Execute and Event Subscribe permissions? Are those permissions only related to dynamically generating events and subscriptions at Runtime? Or do they enable the User/Group to execute a custom event at Runtime?
Correct, events that are based of DataChange and Alert run in the platform super user context
For timer events you can specify security context
and then custom events you can provide specific security context