I think this goes to whether or not Helpmaster is going to be a product that supports multi-tenancy. For my two cents, Helpmaster is a really good product for SMEs or single departments of larger organisations. There are many good products for enterprise environments and multi-tenancy applications but few good products for SMEs. There is a risk of feature creep in the CRMs and ticketing software space to gradually convert the software to suit enterprise environments (since they have the most complex requirements). So, I would encourage PRD to keep focusing on what Helpmaster is good at and carefully consider which features it implements.

For this specific problem, maybe a technical solution can be achieved outside of Helpmaster, such as setting up network drives for different groups all mapping to a common drive letter/path.

Hi Josh,

You make some good points however, HelpMaster already supports multi-tenancy to some extent e.g. the security model is designed to separate access via Skill Groups and Job Security Roles. Also the Web Interface separates end users by Sites. We have some clients who are service providers that support multiple organisations requiring isolation and separation for each of their clients. So I believe that this can be achieved without compromising HelpMaster's existing strengths by implementing this as an optional setting. That's my 2 bits worth anyway.

Perhaps just to expand a bit on multi-tenancy... One example is my current employer where we have an instance of Helpmaster serving the IT department.  The IT department requires about four security roles (HM admin, IT Manager, Staff, Helpdesk), two sites and five skill groups (FLS, Networks, Applications, Database, Desktop Support).  We have different types of jobs (all the ITIL classics: incidents, service requests, change requests) and categorisations (Hardware, Software, Database, Network..).  I think of that as single tenancy.

Now, let's consider servicing the requirements of our Facilities & Services business unit with Helpmaster.  Their jobs are things like changing light bulbs, fixing air con, fixing a broken door handle, removing graffiti, etc.  They will need skill groups for electricians, plumbers, painters, builders, etc.  They'll need a different issue hierarchy (unless the root level element is separated by tenancy).  They'll need different security roles (Reception, Staff, Contractor, Manager).  This is again a single tenant.  While it would be possible to run both business units with the one instance of Helpmaster, it would probably be better to create separate installations or look at enterprise scale software.  The reason for looking at a true multi-tenancy application would be for senior management to have consolidated reporting or for the transference of jobs between business units (eg: a data point installation might require work to be done by both business units).

But then again, compare to an ISP.  An ISP has multiple departments doing vastly different things (sales, support, accounts).  I have no doubt Helpmaster could manage that kind of multi-tenancy environment quite effectively. So it depends.

 

Yep, multi-tenancy is a tricky one, and like you say, it depends on what the definition is, and business need. There are a lot of options and design considerations - not just for actually developing the software, but also for the business configuring it.

We've had quite a few requests over the years to improve the attachments folder locations, and isolating other aspects of the configuration. v15 does have some improvements in this area, and we've got a big new feature coming up that will really help to separate areas of concern and assist with the partitioning of system codes, templates and other groupings.

Regarding the storing of attachments (original post), there are a few options worth considering..

1. Store all attachments in the same commonly accessible network folder
This is the current way HelpMaster works. This becomes problematic when there are many attachments. Over the years, the file-system builds up, and searching and browsing slow down. Possible improvements would be to archive attachments into "Yearly" folders or similar date-based archives.

2. Store attachments in separate "Site"-based folders. Each site has it's own attachments
3. Store attachments in separate "Client"-based folders
4. Store attachments in separate "Skillgroup"-based folders. - This is the original suggestion. The problem with this is that this model is very much an isolated, multi-tenanted approach. If the job is ever assigned to another skillgroup, what happens to the attachments?
5. Store all attachments in a database. No file system, but will bloat a database pretty quick. Possible speed issues. Good for access though and has many "security"-related possibilities.
6. Store attachments in folders that correspond to what entity they're attached to. Jobs would be grouped via date, or perhaps site/client?

Perhaps a hybrid of all of these will work, with system options to choose?