Multiple Agents in Different Companies: Company Details

[chrisvwn]

Hi,

I would like to set up a scenario where multiple support companies have agents who can login and attend to tickets logged particularly to them. Something like a multi-tenancy/hosted environment except there is only one OTRS setup and only one overall admin.

I intend to implement this using distinct groups and queues for each supporting company. (I hope this is right)

However, I would like to have the details of each support company saved in the system and visible on the tickets. In addition, I need to have a public page where the supporting companies can be searched and displayed showing full company details including location, URL etc as well as the ticketing statistics.

I hope this is clear. I'm new to OTRS and would appreciate any assistance. (OTRS 3.3)

Thanks,

Chris

[crythias]

So if you're in disaster recovery mode or upgrade, *all* your companies will be out of service simultaneously?

[chrisvwn]

Yes actually. I know it sounds warped but yes.

[chrisvwn]

Okay. I think it will be easier to ask for help if I explain what I am trying to do.

I am trying to set up a helpdesk system that serves customers of multiple companies. The number of companies is could easily run into tens or hundreds of thousands. Customers are not unique to each/any company and could have separate requests for multiple companies.

The OTRS will be administered by staff who are not affiliated to any company and instead serve as a hub i.e. customer requests are received in OTRS and the OTRS "admin" staff log in as admin agents and assign these cases to the specific company agents. The company agents are created as requests are received so CompanyAgentA will only be created at the point where a customer request is received for CompanyAgentA.

In my implementation each company agent will have an associated queue, group and role. That means tens of thousands or more queues, groups & roles. Is this practical? Is there any limit on the number of queues, groups and roles one can create?

As per my initial post to have searchable companies in public, I will be trying to extend the group object to add dynamic fields to store company information. This will then be searchable using the SOAP API via a public facing company+tickets search.

Does this make sense? Is there a better implementation of this structure in OTRS?

Thanks,

Chris

[crythias]

This probably is beyond the scope of a free forum to provide advice on this particular implementation. You should probably hire some consulting services.

[reneeb]

I wouldn't use OTRS that way. It will be a nightmare to administer that OTRS instance as that would mean likely lots of ACLs, lots of scrolling (thousands of queues won't fit in one screen ), your architecture must be scalable as your proposed solution would probably mean ten of thousands of HTTP requests and ten of thousands of SQL queries per second, your database will reach the gigabyte size within days. Every company might need some customization so that OTRS fit their needs, the workflows might be different, and so on and so on...

You should work on the estimated numbers of agents, customers, tickets per month, max # of concurrent agents, queues, roles, groups, ... first. Then think about the possible architecture. Can you create a test environment? Do some performance tests and see how your solution (it's not only OTRS, but all components) scales...

[chrisvwn]

This probably is beyond the scope of a free forum to provide advice on this particular implementation. You should probably hire some consulting services.

Noted. I realize I am asking for a bit much here. I have re-thought my design and since the system would only have so many companies after some time and only if the system is adopted, I will start simple and grow it as needed.

Thanks for your input.

[chrisvwn]

I wouldn't use OTRS that way. It will be a nightmare to administer that OTRS instance as that would mean likely lots of ACLs, lots of scrolling (thousands of queues won't fit in one screen ), your architecture must be scalable as your proposed solution would probably mean ten of thousands of HTTP requests and ten of thousands of SQL queries per second, your database will reach the gigabyte size within days. Every company might need some customization so that OTRS fit their needs, the workflows might be different, and so on and so on...

You should work on the estimated numbers of agents, customers, tickets per month, max # of concurrent agents, queues, roles, groups, ... first. Then think about the possible architecture. Can you create a test environment? Do some performance tests and see how your solution (it's not only OTRS, but all components) scales...

Thanks reneeb,

I have re-thought the design. Like you said, all those queues would be unwieldy and performance would definitely be affected. I am considering opting for a single queue with multiple agents in groups. For company information, I will create a separate company_info table linked to the groups so I can link the data externally to OTRS via the API.

Thanks again.