One single client managing many CustomerIDs

[xga]

Hello everyone!

I am newby with OTRS and I am not sure if this is the right place to ask questions like this one. Could it be possible to allow a client to connect two CustomerID and open/manage tickets of both? Our ideal scenario would allow a client to choose among his related CustomerIDs from a drop-down menu (like other parameters).

About this scenario I have some doubts (if possible, of course), like how the system would process a email sent to OTRS inbound email? Basically, which CustomerID would be selected?

I have tested the supervisor client explained on documentation, using the field CustomerIDs, but in this case it would never be able to open tickets for a CustomerID different from its main one. I also tried by creating the client ID for each CustomerID, but system doesn't allow duplicated emails.

Could this scenario be possible? How?

Thank you!

[crythias]

In your parlance, what does "manage" mean? Agent side or customer side?

how the system would process a email sent to OTRS inbound email? Basically, which CustomerID would be selected?

The CustomerID that is assigned to the email address who sent the email.

it would never be able to open tickets for a CustomerID different from its main one.

You would open a ticket for the customer, not the CustomerID.

Could this scenario be possible?

No.

viewtopic.php?f=60&t=7531

[xga]

Thank you for your answer, crythias. After reading your post, I agree my first post was a little confusing.The tittle try to sum up the idea of one single user capable to contact manage support tickets for two different CustomerIDs.

I will try to explain myself again but deeping on the scenario:

We have a middleman between a couple of final customers and us. The support procedure would be for both of them as follows: final customer contacts the intermediary and he reports us whatsoever problem. The middleman demand us just a single credentials for our support system which allow him to open, update and manage tickets for both final customers and himself. Our internal requirements force me to create a account (CustomerID) for each final customer in the case of some final customer ask for direct access to our support platform out of intermediary worktime

So,these are the elements of the equation:

Final Customer #n can open, update and manage tickets for CustomerID#n
Middleman can open, update and manage tickets for all CustomerIDs joined to him and his own tickets

Final Customer #1 \_ ->CustomerID #1
_>==> Middleman--->[ OTRS ] =< ->Middlaman's Company
Final Customer #2 / ->CustomerID #2


The email questions were related with the case that a ticket is not opened by the intermediary on our web page but by email. Thank you very much for your answer!!

Regards

Xulian

[crythias]

A CustomerID isn't a customer. A login/email address is a customer. A CustomerID is used to determine what tickets the logged in user can see in the customer web interface for Company Tickets.

You still haven't said whether the middleman is an agent or a customer.

This scenario that you've described has no direct implementation in OTRS.

If indeed a middleman can open, update, and manage tickets, he'd be an agent.

There is no built-in management for just customers in customerIDs joined to an agent, as there is no "customer joined to agent" entry.

if a middleman can manage his own tickets, he'd be a customer.

If a middleman would open tickets on behalf of a customer, but would not deal with followups, you can create a webform that, essentially, spoofs the customer's email address as sender, but the ticket would be created as if the customer would create the ticket, and therefore the customer deals directly with the service provider after this. You can include X-OTRS-xxx fields to "tag" the middleman as the referring middleman.

If a middleman would open tickets on behalf of a customer and deal with followups, you could just ignore the fact of customer to the service provider and have the middleman create tickets himself as the customer and behave like a customer in OTRS, but fill a dynamic field related to the customer (email? multi field demographics?) for which he's creating the ticket.
(To the service provider, the middleman is ALWAYS the customer, and the middleman will not be an agent.)

With regard to an email, you could use a postmaster filter for keywords.