Permissions/Roles Suggestions - More Granular Approach?

Answered

Comments

50 comments

  • Simon Wüthrich

    +1 for Michael ;)

    Hi Sara, thanks for keeping in touch. One use case: I test Podio as a tool for my PR work. My Workspace «Corp Comms» contains several apps. «Blog» for example is an app that everybody in this Workspace should be able to access; «Media Content» however contains cnfidential information and should not be accessible to everybody in the workspace.

    Hope this helps.

    Best, Simon

    0
    Comment actions Permalink
  • Davvi Chrzastek

    +1

    1
    Comment actions Permalink
  • Sara Høeg Højlund-Rasmussen

    Basically it is a very difficult balance to keep the simplicity of Podio and not add too much complexity, we want to keep adding new features but we are also afraid that adding to much permissions will increase the complexity (both within the product and for people using it). It might be prioritized in a later stage (so please keep voting) but to be honest it is not within the current shot-term roadmap.

    //Sara - Podio

    -1
    Comment actions Permalink
  • Michael Trachtman

    Fair enough. To do it right, IMO, you need groups, roles, and permissions, which certainly add complexity. I think though it would be an opt-in thing, for premium accounts, so your existing user base isn't fussed.

    App Roles

    Start simply with a fixed set of roles (Manager, Editor, Reviewer, Reader) for an App, each role having a fixed set of CRUD-like permissions (Create, Read, Update, Delete). Ex:

    Manager: Read/Update/Create/Delete/Manage

    Editor: Read/Update/Create/Delete

    Contributor: Read/Update/Create

    Reviewer: Read/Update

    Reader: Read

    In the baseline Podio product, all members of a workspace are Editors except for the workspace admins who are Managers . This is all abstracted away from admins/users…i.e. there is no Roles UI.

    In the premium product, members of a workspace can be assigned to one of the roles with respect to an App and by default, any app items inherit the app's  permission assignments. Managers get the Manage permission which lets them customize the App and assign Users to Roles.

    Per-Item Roles

    Then, roll out localized roles for each app item. By default, users inherit the role assigned to them at the App level. Then you allow Managers to assign local roles to users for each item. So although User A has been assigned the Reader role on an app, a Manager has given User A the Editor local role on a particular item, giving User A rights to edit the item as well.

    If you are looking for a decent implementation in a web-based content management context, check out the Plone content management system.

    http://plone.org/documentation/manual/plone-4-user-manual/collaboration-and-workflow/collaboration-through-sharing

    Anyways, hope this helps somehow, sometime.

    0
    Comment actions Permalink
  • Maksims Miščenko

    Hi folks,

    for us like salesforce we see just one solution. If there will be a specific field permision functions, then it will be great. There are some fields that is more sensitive that others. If we could shitch them just in read-only mode - it would be breat. I don't think it will be very complex. You must just add some checkboxes.

    Thanks.

    1
    Comment actions Permalink
  • Roger Mabillard

    The only way to achieve this currently is to every single content within an app 1 by 1. It is not very user-friendly IMO.

    @podio Please make it happen. It's been more than a year now that this feature has been constantly requested and searched for. See for yourself:

    http://www.google.ca/trends/explore#q=share%20entire%20apps%20with%20external%20members%2C%20podio&cmpt=q

    The main reason personally to have that sharing option is to let my clients and external collaborators post new content in an app. Currently they can only modify an item that I've previously created and shared. This is a bit laborious for such a simple use care.

    Thanks for keeping up with amazing features!

    1
    Comment actions Permalink
  • John Atwood

    I have tested Podio several times over the past 1-2 years, and the lack of granular permissions has been one of the reasons I have not yet been able to move my whole business into Podio. If I invest in a new system it must provide flexible access control. I have budgets that I cannot have accessible to certain employees, and certainly not to every vendor and client involved in a project. We have internal communication and design iterations that are not appropriate for our clients to see. Would our clients have access to our contact records for them, with our notes about them? Yet the benefit of implementing a system like Podio is in bringing clients in.

    In a brick and mortar analogy, I want, and need, my clients to come to our office and meet with us in our conference room, but I can't, at the same time, give them access to our books and every filing cabinet. It's not possible and not appropriate. It's why doors were invented. There are public spaces and private spaces. I don't see how it is possible to conceive of a product in the category Podio is in without acknowledging this and implementing a solution as a core feature, as serious users will not be able to cope with complicated workarounds indefinitely.

    I will continue to look out for progress on this and a few other issues and see if perhaps I will be able to embrace Podio in the future.

    Yours,

    John

    1
    Comment actions Permalink
  • TK Chuah

    Not having granular access control is a deal breaker. I spent quite sometime to investigate the platform and intend to use it as CRM for both our internal sales people and partner. Several problems become apparent

    1. I do not want to have leads visible to all sales person.
    2. I do not want to have customers approached by one reseller/partner visible to another.

    It seems that the recommendation is to create 1 work space for each sales person and partner. However, if I were to do that, I will not be able to see the complete picture.

    So Podio, please buckle up and get the implementation right ! Having per item/per field access control is a must !

    2
    Comment actions Permalink
  • Lundie Pinner

    Throwing my vote in here as well - app level permissions would definitely be a plus. For example we have to have two HR workspaces, one very restricted, and the other open to all employees. The apps within these two workspaces are very closely related and really should be in the same workspace, but for the privacy issues must be separate. If we could set visibility of an app (as a subset of the people who have access to the workspace) that would be really helpful!

    1
    Comment actions Permalink
  • Fred Boratto

    Podio is awesome in most ways but we are about to give up of Podio because one very important (and simple) feature that is missing. We are unable to protect the read access of an record for certains users. The unique way we know is to create two workspaces with different users on them. However this is a very big problem because the information is very dispersed. We would like to have a single workspace for a project with the possibility to hide some information, like strategic, financial or a human resource meeting.

    The problem would be solved if:
    - A record inside an app could have a flag to set it not visible to "basic users".
    - A record inside an app could have a flag to set the users that can see this record.

    If a whole app could be hidden for a certain users inside a workspace it could be a weaker but reasonable work arround too.

    1
    Comment actions Permalink
  • Jascha Schaefer

    LOL I was just testing Podio again and was wondering why on earth didn't I implement this awesome system a year ago when I first tested it?!? Then again I came to the point of "Hey! Does that mean all sales people can see all leads and contacts and everything and not just their own ones??". Then I found this post and yes indeed it seems so. Making a separate workspace for each sales person is indeed not a problem solver because of various reasons. It's so sad that Podio is so flexible but when it comes to one of the most basic functionalities of any CRM, Sales People should only see their own data, it fails. :((((

    1
    Comment actions Permalink
  • Luca Sorgiacomo

    I'll add my two cents. I've been in my company for about six months and I made them test Podio straight away because we needed a flexible platform to help us oganize a lot of different kinds of pieces of information. It's been working great for most things (can't expect it to work for EVERY thing).

    We're now starting a time of high growth and thus we're upgrading to paid, but I can foresee granular permission at the item level will be a necessary feature for us to keep scaling up with Podio. Otherwise in two ears time we'll have to switch to a more enterprise ready (and most likely clunkier, sigh) platform.

    Please Podio, I love the interface and the UX in general. All you need is just making an optional item field that specifies permissions if needed, otherwise you can default as editable by everybody. That would not in any way hamper the user experience or complicate the platform in any way, quite the contrary! You'd be opening yourselves to a whole lot of enterprise opportunities!!! I really can't see why not doing it, unless Citrix is planning a more expensive enterprise version of Podio of course...in which case I'd be really interested in trying it out, but please get that option out in some way or We will have to switch at some point.

    0
    Comment actions Permalink
  • Oliver Wray

    @Luca Thanks for sharing! We have this one on our wishlist, but it is a big project so not on our short term roadmap yet.

    //Oliver - Podio

    -2
    Comment actions Permalink
  • Colin Clark

    We would also like to see something like this implemented.  We currently have an app in place for Support Requests that needs more in depth user permissions,  Currently a user submits their request through the Support Request app.  A Support Manager then gets notified that there is a new request and they review it and either approve or deny the request accordingly and then delegate the task to a Support staff member.  One of the first fields and options in the app is:

    Request Status:
    Request Submitted;   Request Approved;   Request Denied;   Expired.

     

    Some of our users have discovered that they can select "Request Approved" when they submit the initial request.  We need to be able to set it so only Support Managers and Support Staff can modify this field.  The workflow is supposed to be once the task is created, it assigns an approval request to the manager.  Once the manager hits Approved, a task then assigns to the support staff member.  If the requesting staff member sets the Request Status as Approved (which they shouldn't have the ability to do), it bypasses our entire workflow and can lead to tasks getting actioned that are not actually approved.

    0
    Comment actions Permalink
  • Chris Pleines

    Same this is absolutely crucial

    1
    Comment actions Permalink
  • Colin Clark

    This issue was raised almost 4 years ago.  To the good people at Podio:  Is there ever plans to listen to your paying customers or should we start looking for Podio replacements?  

    1
    Comment actions Permalink
  • Chris Pleines

    Yes, still need that. When is that done?

    1
    Comment actions Permalink
  • Vera

    +1

    we start to realize that this is a must for us and we're even considering alternatives.... but actually don't want to!

    1
    Comment actions Permalink
  • Will Lowrie

    +1. The member roles list by Admin, Regular and Light is very clear (https://help.podio.com/hc/en-us/articles/201019898-Member-roles-in-workspaces). However there is little flexibility for administrators. I want to allow users some of the admin level rights e.g. 'delete others' app items' but without granting 'export to excel' rights which appears in the Regular member level. 

    We are always trying to bend the limited functionality of member roles to work for us but feel that unless they become more flexible and granular they will not be fit for purpose in a larger organisation.

    1
    Comment actions Permalink
  • Matthew Ringel

    +1

    This would make our use-case much easier, as well.

    1
    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk