Curious, why do you have servicers as agents and contacts. If they are already agents assigned to the ticket, why then add them as a contact also?
Maybe I'm doing it wrong. But I have them as a user and System Rold = Agent
I dont find any options in the user setup to add fields such as Company Name, Address, Phone Number, Services offered.
Am I missing something.
Am I on the right track in thinking that what you are trying to do is creating a ticket for your customer and then assigning the ticket to a 3rd party company that will provide the service?
And once that connection is made, you want the customer or yourself to be able to see the contact information of the 3rd party company?
Correct. The 3rd party companies are setup as concurrent users who will also have access to Footprints to update ticket info and interact with the customer.
If I did it as a service in the Service Portfolio, do I still have to assign the original ticket to the 3rd party user ID?
I'm basically trying to avoid the two step process and make it simple.
I am thinking that you could assign it to the 3rd party ID and then sent a rule to link to the Service based on that party ID
I guess I'm still confused. If they are agents assigned to the record, why do you also need them to be contacts?
FootPrints aside, can you describe the process start to finish as to how these tickets work.
So had a quick chat with Tracey offline to better understand this. What I'd recommend:
1) Do not build the Servicer as a Contact in an Address Book. Instead, build it as a separate item in a workspace. You have far more relationship and business logic options, and you don't need the Address Book functionality (of tying a contact to a user for the purposes of Customer access or surveys, since your Servicer is already an agent)
2) On your Servicer form, build the fields you need, and add an assignee field with the servicer name.
3) Have your assignee field on your ticket form act as a linked field using a relationship to your servicer record.
Voila, unless I'm missing something.
As you noted that the servicers are agents, then this should work. PIA but doable. Depending on how many servicers you have, you could consider a dropdown if there are a small number, if a larger number a dynamic sql lookup. Then, once you have the field populated, you have the unenviable task of creating rules that evaluate the selection in field and then make the appropriate assignment. But, unfortunately there is no way to populate the assignment field from the value in the field where the selection was made, thius one has to have a rule(s) to cover each scenario. You may also wish to link both in the contact lookup.
Hope that helps, if I misunderstood, my apologies.
2 of 2 people found this helpful
Only thing I would change is use the CMDB for the servicers instead of a workspace item.
i have built several process where I have a support provider as a CI class.
Your ideas and responses helped me think about this more on what I was trying to do and I think I have a solution that is working how I want...maybe not as efficient but it appears to be working.
Workspace called "Customer's Service Tickets"
Two Address Books, "customer address book" and "servicer address book"
Customer address book has our customer details
Servicer address book has all the servicer details (email address, Company Name, address, phone number)
Then we have our users...user name is the company email address and Name is the Company Name
On my ticket form, I have the Assignees field. When you search for an assignee and pick one, I have an On Screen business rule that sets the field value of Company Name from the [assignees_1]
Then I have an After Save rule that Links Existing Record, Link type = Ticket/Contact:Contact, Target Record Type = Servicer Address Book and Links on the Company Name fields.
That ends up populating the fields in the parent ticket with all of the servicer details.