This is a public Idea Center  publicRSS

Idea

    23 liked this

    [Under Consideration] Keep your nose out of other peoples...
    Idea posted June 18, 2009 by MikePInnovator, last edited May 12, 2015 by LawrenceMExplorer, tagged Customer Portal, System Admin and Configuration 
    55131 Views, 15 Comments
    Title:
    [Under Consideration] Keep your nose out of other peoples business! (restrict interface access by org or contact)
    User Story / Description:

    We need to be able to restrict interface access by Org or Contact.  We have 3 (and soon possibly 5) interfaces.  There is no way to keep someone with a log on to one interface from accessing another interface.

     

    Scenario:

     

    Jon (contact at MegaCorp) can log into interface 1, ask questions and view Answers.  He can also log into the Consulting only interface 2 and see things he should not like a custom menu on the Ask A Question page with a list of all of our customer orgs.  He can also log in to the HelpDesk, Interface 3, which is for Employees to communicate with IT.  They could Ask a Question of our Internal IT department which is totally inappropriate.

     

    Just want to keep the keep the foxes out of the hen houses and the hens out of the garden.

     

    Comment

     

    • SabrixDaniel
      I would like to 2nd this emphatically. We have links to get support to each of our 2 external interfaces from our main site, and people can easily get confused and enter the ticket in the wrong interface, which triggers different business rules and makes us miss SLAs.
    • Dietrik
      This is something  I've also missed for a long time. Maybe an extra SLA setting ?
    • MikeP
      SLAs make the most sense since they can be applied to orgs or contacts. 
    • Danny

      We have a large number of departments accessing a single RNT instance. Developing Chinese walls is a big problem. One of our problems is that while the contacts database is shared (all employees and students at the university) we need to restrict the view of incidents to those that need to see them.

       

      This is a major issue with the current focus on security  - particularly FERPA requirements.

       

      The underlying problem according to ProServe, is that in order to access all the contacts in the database, you have to give access to all the incidents (I think I'm simplifying, but that's the general idea).

       

      I can build views in navigation sets that makes it difficult to see incidents in other departments; but if I give analytics access to anyone they get to see it all.

    • MikeP

      Danny,

        This IDEA is about keeping contacts from one interface from getting into another interface.  It has nothing to do with  Admin Users. 

       

        I just think that keeping one idea to an IDEA is a good idea.

    • MikeP

      Wrong thread

    • jdenstone

      We have solved some of this with SLA's.  We have 4 classes of customers:  Shippers, Carriers, 3rd Party. These are the SLA

      We use pass thru authentication for login so the only access to RN is thru our ap.

      When the user wants to view their incidents they can only see their incidents and their associate's incidents.  They cannot see any other company's incidents.

      When the user searches the KB they only see answers that have been flagged for their user type.  So a Carrier company will not see Shipper company answers, etc. 

      Maybe this is an oversimplification but it works.

      Joycelin

    • MikeP

      If we could rely on SLAs we would not need 3 interfaces.  The main sticking point is with the Ask a Question page.  Customers come in and ask questions in interface 1.  Our consultants log in to interface 2, they have many more fields to fill in.  They see a custom menu field with a list of every one of our customers, and so on.  Employees log in to interface 3 and open incidents with our IT helpdesk.  Practically none of the fields are in common with interface 1&2.  We obviously don't want our customers seeing lists of our other customers or opening an incident with IT.

    • RSproul

      I agree with this one and I think the SLA is a good place to restrict access, but it could also be flexible enough to allow access to multiple interfaces.

    • Kurt Helfrich

      I'll second RSproul's thought about multiple interfaces.  We have that situation now.

       

      We do a lot with SLAs connected one-to-one with a corresponding access level to selectively hide/display answers.

       

      I'd like to add anothe thought: control of visibility of products and categories not just  by interface but by SLA.  Presently, if we want to hide a "product" from anyone, it has to go to a different interface.  We've got over a dozen now, with no end in sight.

       

       What's I would like is for an SLA to control which answers, incidents, products, categories and other stuff are visible or available.

       

      That way, for 2 customers, I could show them different lists of products, but only have to maintain one interface.  That would work for a lot of our high value customers without requiring another interface every time.  And customer 1 wouldn't have any indication that there was anything special for customer 2 (who may be a competitor) there.

    • implode

      Along with this I'd like to see the ability to separate the content in the knowledge base from users based on certain aspects about the users: product, org, contact type, or even custom fields.

       

      You have only purchased product X and therefore can only search for documentation on Product X, mostly because you have no idea the differences between products X, Y and Z and we don' t have the resources to train you on the nuances between the products or even that you specifically have product X.

    • Kurt Helfrich

      Have this control apply to chat and AAQ, too.

    • DaveF

      Necro'ing this one - as there were a ton of good ideas that the orignal request spawned. The whole idea of filtering searches by assets (and in the coming months) destination pages for products and categories is something that we've bee working on, in constraining the user to what they are interested in, but don't go as far as some of the requests earlier in the thread for building walls between experiences targeted at different user bases.

      There are some good ideas in the older entries for using SLAs in a more flexible fashion than is currently allowed. My question concerns how administrators would like to maintain this.... Is it conceivable that in your businesses, you can apply SLA rules on contact create/modify (with multi-variate conditions) where outcomes of an SLA - like interface access can then be defined? Are there edge cases where rules wouldn't work in all cases and a contact center agent with the appropriate privileges would need to go into a profile or contact record and set or override a specific SLA governing access?  

       

       

       

    • Kurt Helfrich

      Well, in our case, 99+% of the SLAs are linked to orgs, not contacts.

      I suppose rules would be OK, but we would want a way to import them.  We have over 2000 SLA types, with various requirements associated, which would mean a lot of rules.  Doing them by hand in the current editor would be awful.

      I can't think of edge cases offhand in our situation that would require anything, assuming that the rule or SLA options were sufficiently flexible and granular.

      (I would like rule import and export/backup in general, for workspaces as well as objects like answers, incidents, etc.  We use a lot of workspace rules for access control.)

    • LawrenceM

      Hello Mike,

      We have been going thru suggestions and I just wanted to let you know that this idea is on our list to explore.

      Thanks,

      Lawrence