What access level is needed to monitor processes in "Run time Data"?

I was wondering what level access is needed to be able to monitor processes from the runtime data screen.

I have a particular user who is of type "basic user" and is part of the "Designers" group so it can access the runtime data screen and view the process list but is unable to monitor the processes. I would like for this user to be able to do so.

Any ideas on how to achieve this?

  Discussion posts and replies are publicly visible

Parents Reply Children
  • +1
    A Score Level 1
    in reply to oscarb0002

    From playing around in a separate clean environment, the short answer seems to be yes, but the longer answer is it depends.

    You'll need to make sure you have security implicitly defined elsewhere, Apps, Rule Folders, Process Folders, etc.

    I set my parent Rule Folder to have implicitly defined security (i.e. Administrator and Viewer, with default as Viewer) and all children inherit from the parent. Any objects that existed in these folders could not be modified manually or upon importing patch or new app.

    I created a process that gave the user Process Administrator rights in an application with default Viewer rights and process model folder has default security set as No Access, and tried importing a patch and the process model wasn't updated.

    However, the user was able to import a new application with new objects that were not in the existing folders.

  • Thank you very much. It seems like this could be a potential workaround. I need to run this by the client's risk and security team but I think it might fly. It has been of great help.
  • Hi  ,

    Your requirement all comes down to the fact that what level of access you provide for the user and what your business and organization security concerns/levels.

    I believe the user is part of the support team who wants to debug and monitor processes.

    First thing a basic user can monitor a process given the right level of access to the process model instance.

    There are two way of doing this.

    1. Providing design level access:- Add the user to the Group that is mapped to process model as Administrator. :- This will give access to design time process model as well as run time process instance. (This may have security constraints as non system admins will get admin level access to design time objects in production. But it all depends on organization security measures.)

    2. Provide run time access :- Add modify process security smart service in the start of main process model and define a new group in administrator field and other required fields as necessary. :- This will only provide access to running instance. Not the design time process model. You can inherit the security to sub folders also. But this configuration should be adopt very carefully as to initiate a main process/sub process you still need initiator level access that is set in design time. (From security perspective non sys admin users will not get admin level access to design time object but still get admin level access to running process instance.)

    Hope this helps

    Regards
    Suresh