We are using CA SDM 12.9.
Can we pass the tenant name through email while creating maileater incident tickets?
Currently we pass tenant UUID.
Hi Chirag, again, as I mentioned earlier, tenant is chosen based on the tenant of the affected end user. The affected end user/requestor is based on the "from" address on the email that is sent in. It matches the email address to the contact table and then creates the ticket under the tenant of that contact which sent the email. Thats why its working regardless of whether you use the UUID or the Name because its using the from address and putting the ticket under that user's tenant. Additionally, end users will ONLY be able to create tickets via email under their own tenant. Only an analyst that has rights to create a ticket under a contact for another tenant would be able to do that.
Mailboxes are tenanted themselves, so I am not sure that passing the tenant UUID would do anything since its not a field available in the text_api.cfg. Also I believe that it would create a ticket based on the tenant of the requester.
I checked by passing %Tenant=Tenantname and it is creating tickets in the specified tenants even though the %tenant has been defined to accept UUID in the text_api.cfg.
Not sure how that is working exactly.
A few questions:
As Jon had stated, mailboxes have their own tenant attribute, so it's not clear to the purpose of passing tenant information as you mentioned.
The requirement is for users to be able to create tickets by sending emails.
UUID is being passed using field %Tenant which has been defined in the text_api.cfg as %Tenant=tenant.UUID
Additionally as a side note - if your goal is to have end users be able to create tickets under different tenants that are NOT the tenant on the contact which their email address is associated with, it will not work unfortunately. Multi-tenancy is just not designed that way.
and we want to keep like this
Imagine an MSP where any client can send email and create ticket in another client tenant.
Will be a big breach
Correct jmayer - this will not change. It is the way it was designed and the way that MSP's are using the product currently.
We havent heard back from you on this one regarding clarification of what you are looking to do here, and what is driving it. If you still need assistance on this one, please provide the info that David and myself asked about, so that we can give you some help here.
Thanks for your inputs everyone!
Retrieving data ...