Setting up Admin Access to Leads Only for 3rd party

We are working with an outside source that wants to use Zapier to access leads we have limited to a field selection for them. My question is can I set up an admin account for them and they will ONLY be able to access those leads as long as I put them in the same team I set the other user on that only has access to those particular leads? As an admin they won't be able to change that or get into anything else correct? 

Parents
  • I'm not on Enterprise yet, but when we get there, I was thinking to give our world-wide Resellers access to their Assigned Leads by establishing Teams for each Reseller and assigning Leads to those teams.
    Then leveraging the Customer Portal to let them see and work those leads.

    Would that be a viable option?

    FrancescaS

  • Hi ,

    The customer portal that comes with Enterprise does not adhere to a team-security model. User accounts are provisioned through an accompanying contact record rather than the Users module. The credentials associated with a contact are then used to log in and provide visibility to related records. (e.g. all cases associated with the account related to the contact) The contact is ultimately using a single, designated 'portal API' user to communicate with Sugar so team & role security are tied to that single user. The end-user portal visibility model is based purely on relationships and not team memberships as far as I can tell. For instance, if the contact is related to the 'East' team and a case is related to the 'West' team, the contact can still view and interact with the case in the portal.

    I say 'as far as I can tell' because it appears making additional stock modules visible in the portal appears to be broken. I added Accounts, Contacts, and Leads to visible portal modules and deployed the change:

    At that point, only the Contacts module was added to the header menu in the portal and accessing the module gave me a 'Data not available' error. I started hunting around the documentation and saw a mention of modifying the 'Customer Self-Service Portal Role' to fully remove a module from portal access and figured maybe those 3 modules needed to be enabled on the role. Out of the 3 modules I originally added, Contacts was already flagged 'Enabled' in the role while the other two were 'Disabled'. I enabled them and updated all 3 modules to have the same role properties of the Cases module:

    Unfortunately, that didn't change the behavior for any of those modules after logging out and back in. I tried accessing Accounts and Leads by manually changing the URL and received an error "Error: Issue loading module. Please try again later or contact support."

    All this is to say, when/if those modules are fully functional in the portal, I don't think your use case is viable without code-level customizations. 

  • Thank you

    It looks like the Portal may have big challenges even in its native state given that our Contact-Account relationship was changed back in v6 to be M:M and, of course, our Cases are also somewhat customized...

    This will require some degree of my favorite activity: reverse engineering. Wink ...followed by next favorite... creative coding!  It's what happens when you know just enough to be dangerous... Laughing

  • Hi and , I just wanted to clarify a couple things:

    1. It is not actually expected behavior that modules besides Cases, Bugs, and Knowledge Base appear in the list of available modules for the portal OOTB. This was actually just fixed in 12.1: bug # 84691.

    2. The portal visibility settings that Chris mentioned (case, email, and message visibility) are actually only available in Sugar Serve. See the "record visibility" item here: License Types Matrix.

Reply Children