Configuring a Run As User for Integrations
Each integration must be associated with a user account in Loftware Enterprise™ SP under which print requests from an Oracle application, from an SAP application, or by file drop should be run. Run As user accounts are typically not interactive. You should create the Run As user for an integration before you create the integration. You can use the same Run As user for multiple integrations.
It is recommended that you create a group in Loftware Enterprise SP for Run As users for integrations so that you can manage permissions for those users as a group. To provide the most commonly needed role-based permissions, assign the INTEGRATOR role to the group that you create and then add the Run As users to that group.
Note: If the process or business rule associated with an integration performs actions that require permissions beyond those included with the INTEGRATOR role, you must ensure that those permissions are granted to the Run As user. For more information,
Important: Access in Loftware Enterprise SP requires both role-based permissions
Permissions that are assigned to a role and inherited by users who are members of a group to which that role is assigned or by users to whom the role is directly assigned. A user must have both a role-based permission and the corresponding object access permission to perform an action on an object. and object access permissions Permissions in Loftware associated with a specific object or with a folder that control what actions can be performed on that object or on objects within that folder. Each object has default permissions that can be overridden by exceptions for a specific group or user. A user must have both a role-based permission and the corresponding object access permission to perform an action on an object.. For a user to be able to perform an action on an object, the user must directly or indirectly be assigned a role that grants permission to perform that action on that type of object. Additionally, that particular object must either be in a folder that directly or indirectly grants the user access permission to perform that action on that type of object or else that particular object must directly or indirectly grant permission to the user to perform that action. There are several permissions that are only role-based or only object-based and do not require a corresponding permission. Examples include List permission for Folders and all permissions for Model Status (Auto Refresh), Tag Categories, and Devices.
The following object access permissions are typically necessary to support integrations. Additional permissions may be required to support some processes and business rules.
- Folders containing device groups to be used in conjunction with an integration should grant the group that you create for Run As users Read and Print permissions for Device Groups.
- Folders containing label templates, layouts, images, or business rules to be used when printing via an integration should grant that group Read and Print permissions for Documents.
- Folders containing processes used by integrations should grant that group Read and Print permissions for Processes.
For more information about configuring users and groups and about granting access to objects,