View as user or view as role

JasonAltenburg
JasonAltenburg Contributor
edited August 2023 in Domo Developer Ideas

As an Admin / Major Domo

I want to view my Domo Instance from the perspective of a selected user or role

In order to ensure their experience aligns with what is expected. (Dashboards, cards, pages, features, etc. that they should see are there, and those they should not see are not visible.)

74
74 votes

In Review · Last Updated

We are evaluating the set of tasks that would be enabled by 'view as' to determine the right approach.

Comments

  • This is a great idea! This would be helpful for validating PDP policies

  • OMG… yes, that would be huge. I would even ask to take it a step further and as an admin be able to mirror or impersonate an individual user.

  • This would be a great addition - my IT team has been in contact with Domo regarding this same feature.

  • This feature is extremely important to the successful adoption of Domo within our company. It would provide the ability to validate our security policies, greatly reduce the time spent trouble-shooting access related issues, and improve the user's overall experience.

  • Great idea. This will make content creator's life so much easier when they know what their user would see.

  • DomoDork
    DomoDork Contributor

    I'm working through PDP automation as a new customer and this is exactly what I struggle with. Since I can't impersonate other users as Admin, it's extremely difficult to verify and audit that PDP is working as expected. This would be HUGE and very much needed.

  • 100%.

    Trust and a more positive user experience will come from our Dev team being able to catch authorization issues. Whether that’s seeing if PDP works correctly to have card/page access set correctly.

  • TheLookout
    TheLookout Contributor

    DomoSupport can already do this. Making it available to customers would be fantastic.

  • I need this. has this updated yet?

  • @arashhemmasian_2023 as of yet, no.

  • swagner
    swagner Contributor

    @JasonAltenburg great idea! I have a [email protected] account I use for this specific thing, but it's limited. Would be so much better if we could do as you describe.

  • This would be huge for us. We have tried to do as @swagner recommended but it is limited and time consuming.

    If I solved your problem, please select "yes" above

  • This would be great!!!. What I do know is to create a temporary password and log in to see how the user's dashboard is looking.

  • +1

  • JordanJensen
    JordanJensen Admin
    edited November 2023

    Our initial investigations on impersonating a user generated a few feasibility questions related to security risks from allowing someone to impersonate someone else and possibly take actions as a proxy. Impersonating a user bypasses the access controls and policies applied to the user who is impersonating and we need additional research on viable options. To help us find the right long term and potential short term workarounds, can you all help me confirm the below 'jobs to be done' that we should be solving?

    • Governance / Access Control
      • validating PDP
      • validating access/security policies
      • troubleshooting access related issues
      • validate data sharing methods
    • User Experience
      • validating user experience aligns with what is expected
      • understand current experience of user and what they see
      • discovery to improve user overall experience

  • @JordanJensen Those jobs all look correct to me.

    The security aspect is a fair note. I think in this regard, the key word is View. I would think that in the view as experience, you would have READ access to cards and dashboards, no create update or delete privileges as the other user. Possibly a blend of restrictions could be considered where the MOST restrictive of the two users policies would take effect. I think this would be a Superuser / Instance Admin type of grant to be able to use such a tool.

    I think in my experience as Majordomo, I was looking for what falls under the User Experience bullets.

  • As a Domo admin I can see everything anyway so I am not sure why it would be a security issue. Agree with @JasonAltenburg that it should be a grant related to the admin role.

    If I solved your problem, please select "yes" above

  • @ColemenWilson I apologize for any confusion. The security concern was not related to being able to see everything as to your point, you can see that as an admin. It was the concern with you taking action as another user. We will need to ensure we engineer the ability to track when you took an action as a user you are impersonating.

    @JasonAltenburg I think I am following. Your suggestion of 'Possibly a blend of restrictions could be considered where the MOST restrictive of the two users policies would take effect' is interesting and am wondering what impact that would have on your ability to validate their experience. Is there any value in making setting up a dummy user like '[email protected]' easier? Or, do you need to validate the experience as a real user?

  • Oh no, that would not be secure at all. All we are looking for is a view as user or view as role - "view" being the key word.

    If I solved your problem, please select "yes" above

  • nolan
    nolan Member

    Excited to see some traction on this! As I'm developing a better mental model for how permissions on various objects / roles / PDP interact this would be really helpful. And avoid the "Can you share your screen? How about now? now?" conversation :)

  • @JordanJensen I think there's some assumptions built in to that question about the Domo Admin being an IT Admin or having the power to set up a service account / test account.

    In addition to this, imagine what that would look like to validate the experience in Domo of in a hypothetical small 6 person Domo instance with you as CEO, and your CFO, CMO, COO, CTO, CIO… you would need to create the 7th test user, then need to add then remove all permissions to your test account each time you wanted to view someone's experience. Add CFO … remove CFO add CMO… remove CMO add COO… instead of having an ability to "view as" to ensure that they all have the expected Domo Interface.

    The idea around restrictions and permissions, if you could blur or placeholder cards I don't think it would be an issue. Most of the time it would be helpful simply to quickly understand what it looks like when they visit a page. I do understand though that some companies have more restrictive controls around their data where this feature might just need to be completely disabled by a CSM / Superuser

  • As an admin and the person responsible for an overall positive Domo user experience, this is an imperative management feature.

    I intentionally laid out the sub-page order for a deployment to a group of 10 users.

    The page order had intentional logic to support adoption. My directions referenced the page order.

    Weeks later I learned that each user got the pages in a completely randomized order.

    Many of my administration challenges come down to "I cannot see what you are seeing"