Process model viewer groups

There are no groups/ ways to secure design objects with process instances this way! Being admins they will be able to see instances and objects both. 
Also I have never heard of a scenario like this so can you share their reason behind this ask? 

You're correct - there's no built-in view-only group for process instances.
Alternative, Create custom dashboards or reports to show just process instance data(Include all details) to support teams.

While not an direct answer to your question, I typically implement support like described in this blog post:

appian.rocks/.../

Thank you all for your response. Client engineering team doesn't want Prod support team to go through the design objects. They wanted to reduce unauthorized access, avoid misuse of API endpoints, business rules.

we did similar for one of the clients but i don't think this would still help us here.

 Shubham Aware nice seeing familiar face. hope you are doing well. 

Custom dashboard may be way to go, but i  need to think about building it for overall application. Also, not sure about process report include failed instance for eg exception, error. Anyway, thanks for the suggestion. i will explore more on this.

This has come up for me before, and the closest compromise I could offer was that the objects would be visible in "Read Only" status. From a governance perspective, this was acceptable to the stakeholders at the time. This was achieved with an app-based "Tech Support" group that was inserted into both the "All Users" group and "Designers" group. Users in this combination of groups will

• See objects (and objects' test cases) in "read only" mode for the target app AND any other app where they're in the app's "All Users" group
  
• Be able to click the "Test" button on objects
  • This includes Web API components, but also keep in mind that users abusing this would show up in the web api logs
• NOT be allowed to click the "Start Process for Debugging" in process models, nor see the PM security from the process modeler
• Have the same permissions to the app front-end as any other set of users who are only in the "All Users" group (versus a sub-group), so keep that in mind if they're not allowed to see data or action tasks
• Be able to see process instances and re-run nodes as they exist, but NOT edit nodes (via 'Edit Process View') before re-running
• There are a few additional view-related capabilities / caveats, but they're not related to objects / process instances.

thank you for your reply. Yes currently we have done same thing in our environment. but still client don't want to view the design object in read only mode. I have to tell there is no OOB solution for this. 

I have a suggestion which basically involves securing the objects of application tightly so that support team can access just process model and nothing else. It goes like this - 

1. Ensure all Support Team members are assigned the Basic User role in the Admin Console.
2. Add users to the "Designers" system group to grant access to Appian Designer.
3. Create a dedicated Application that exclusively contains the process models used within the application.
4. Create a group specifically for Support Team members.
5. Assign Viewer permissions to the Support Team group for all process models and the application.
6. Apply appropriate security configurations to all other applications/environment objects by mapping them to relevant groups so that none of the object is orphan/without any security configured.

With the above the support team member will see just one application in environment which will have process models. Apart from process models this group won't have access to any other object. The team would be able to check monitoring instances. But cannot edit them. They will not be able to see CDT/record type based process variables data as well in the instances as they won't have access to underling record or cdt. 

I feel the need to point this out - the O&M team members will ALMOST ALWAYS require full visibility into design objects - otherwise, effectively performing O&M support (including the necessary debugging, troubleshooting, and/or tracing work) will occasionally be totally impossible.

So the dev team CAN bend over backwards to install something complex and fairly cumbersome in terms of hoops the support team must jump through - but in my professional opinion it is NOT a good idea and it is NOT sustainable.  Unless you want your O&M personnel to quit after 2 or 3 months.  Your client is free to talk to me directly about this if they need further reassurance that their requirement is a bad idea.