2 Replies Latest reply on Dec 2, 2016 9:20 AM by kfoster

    Setting Up WHD in K-12


      I am with an IT department in a district with 7 school sites.  We just purchased WHD for our department, and I will be setting it up.  Before I start, I have some questions about organizing companies and locations.


      Eventually, our district would like to add WHD for maintenance and HR, each with a separate url and branding, but we would like continuity within the database.  I am wondering how to accomplish this.....

      • Should maintenance, HR, and IT be companies within one instance of WHD and the schools be the locations?  (I'm thinking there can be only be 1 url and branding this way.)
      • Should we have a separate VM instance of WHD for maintenance, HR & IT with each school being a company (or location)? (If we have separate VM instances, then I'm thinking the database won't be shared.)


      If you are in K-12, how have you set up WHD for your district?


      Any advice is greatly appreciated!  Thanks in advance for any suggestions you can share!!

        • Re: Setting Up WHD in K-12

          Some thoughts/info:

          • It is not possible to have a different URL/branding for different locations/departments within one WHD instance. 
          • If you did need completely distinct environments to facilitate that, they would be licensed completely independently.  You are correct in assuming that the database would not be shared in that scenario.


          • You can certainly have one WHD environment that covers everyone; within the product you can route Request Types to appropriate Tech Groups, so all maintenance-related tickets could go to the Maintenance tech team, and all HR tickets would go to the HR team, etc...    In such a case, you do have the ability to restrict your Tech users to only see the tickets from their Tech Groups.   An Admin user can see/do anything, but a regular Tech can be restricted in that way.


          • I would not use Companies for the HR/IT/MAINT groups.   Those are much better suited to being Departments rather than Companies.


          • Locations can 'belong' to Companies, but Department is a completely separate designation that is not related to Companies/Locations.    So, I could have a Client (end-user) that has their Department set to HR and their Location set to Austin.    My environment has Location 'Austin' tied to Company 'SolarWinds' so because of that relationship when i look up this user i also know that they are in Company 'SolarWinds' because of that relationship.
            • You can make certain Request Types visible only to specific Locations, Companies, or Departments.     For example if i have a Request Type called 'Playground Equipment Repair' but only 2 of my Locations have playgrounds, i can limit who sees that Request Type to only those two Locations.
            • You can change the name of "Company" and/or "Location" as they are displayed in the system as a whole.        So, you could effectively rename Company to show up as Site     and Location to show up as Building       OR    you could effectively rename Company to show up as School and Location show up as Area (which might be things like '1st floor' or 'east wing' or whatever else makes sense).    This would be done by changing the "Label" for that entity in a config file as described here.
          1 of 1 people found this helpful