FAQ and Troubleshooting
Last updated
Last updated
This option is not yet available, please share your automations via the overview of the automations, like in the following picture,
A user can access an element he has read permissions for and in this view mode he can change the element but he is not able to save the changes.
Either you are also part of a different group that has access to other elements or there are elements you own (because you created them) that were not shared with the group.
If you want a user to be able to change an element make sure the element is shared (with write access) with one of his groups and that he has write permissions for this part of the application.
If you want a user to be able to see an element make sure the element is shared (with read or write access) with one of his groups and that he has read or write permissions for this part of the application.
No, you need to explicitly share an element with groups, even with the ones you are part of.
Yes, if you have write permissions for a component of the platform or an element you also have read permissions.
In this case, you can not look at this element directly. But let's say you do not have access to the dataset and script editor. If a script or dataset is shared with you, you can use it in a widget, but can not access it directly.
For the dashboard to work as it is, no. But the user will not be able to alter the sub-elements and if this user removes a sub-element (e.g. a widget) that was not shared with him, he will not be able to add it to the dashboard again.
Usually, there are two super-admins one is owned by Senseforce, in case we need to investigate problems on your platform, and one is owned by a member of your company.
The super-admin has write access to all elements and access to all things on your platform.
As soon as you are starting to get more than just a couple of users it is important to think about a concept for your user management.
There are basically three dimensions in our permissions system, i.e. access to things, components, and elements. If you think of every user in terms of these dimensions you will get lean and understandable group management.
In terms of thing-permissions, you need to consider that you have two customers, which are only allowed to see their machines. Hence you create two groups with permissions to the machines of each customer (and maybe a group for internal users with access to all things). You might also have different roles, like manager and technician. The manager group should have access to the organisational dashboards and the technician to the technical ones. So one group with access to the respective elements for each role. At last, you might have different types of users, some might only need to view content, some need to create content. Create groups with different permissions in terms of the platform components. Now let's say we have a technician from customer 1 who needs to create widgets and dashboards. You can assign him to the groups "Customer 1", "Technician" and "Creator" and he/she will have all the necessary permissions.
