Integrations and APIs for Service

Get Involved. Join the Conversation.

Topic

    bryan.arndorfer
    "Moving" Contacts to a different OrganizationAnswered
    Topic posted December 17, 2010 by bryan.arndorfer Bronze Medal: 1,250+ Points, last edited October 29, 2011 
    1442 Views, 4 Comments
    Title:
    "Moving" Contacts to a different Organization
    Content:

    I know that the contact_move function is not available in the APIs  at present.  And I know that setting the contacts.org_id = x and calling the contact_update API will not work.

    So we have created a tool that checks the RightNow interface for the contacts that we want to have automatically moved into a specific organization.  It grabs them with all their contact specific information, puts it into variables, and creates a new contact with the organization ID I want.  While it is doing that it deletes the current contact.

    Before it starts to move that contact I first check if it has any Incidents attached.  If it does, then I move them to a temporary location.  Once the new contact is created then I move the Incidents to the new contact ID that was created under the new Organization.

    This process is working great.  

    However, as expected there are some objects that are getting deleted/orpaned with that contact_delete API call.  The one that I am interested in at present is surveys.  I don't see any APIs available in the current version I am working with, to work with the survey(XML can start a campaign), or in Nov 10.  

    Is there any way that I can recreate those surveys, or "move" those surveys to my new Contact ID?

    Interface Version: Nov'09

    Language: C# -- Can switch to accommodate another method

    Best Comment

    Ryan McCullough

    I would definitely recommend not doing that (php script with direct SQL). It is dangerous, could create inaccuracies in reporting, and is not upgradable.

    At the very least you should use the contact move function rather than direct SQL. Even still, we have not exposed that function because the consequences are not understood by most users.

    When we get the request for "contact_move", we start by asking why they need it. Most of the time, the user doesn't need to move the contact record, but should be creating a new one (sometimes even if it is the same person). If the person has changed organizations, most of the time they have a new email address (I know this doesn't apply if they changed divisions in the same company and each division is an organization in RN CX).

    Scenario:

    Customer John Smith works for Organization WidgetWorks. John changes jobs to FooForgery. If you "move" John from WidgetWorks to FooForgery, now all of the incidents John created when working for WidgetWorks are also moved to FooForgery. This means that WidgetWorks can no longer see those incidents and that FooForgery can. This could be serious depending on what kind of information is in those incidents.

    This is why we have not exposed contact_move in our integration APIs.

    The recommended way to "move" a contact is to get the source contact, copy all of their properties to a new destination contact object, update the source contact's email (if they will be the same) and update the contact. Update the destination contact's organization id and create it.

    Comment

     

    • Walter Kamp

      Hi,

      I would definitely change the orgID. That's much easier than recreating all the objects.

      You can do this by creating your own (simple) PHP file that runs a direct mysql code like this: UPDATE contacts SET org_id=x WHERE c_id=y

      Cheers,

      Walter

    • Ryan McCullough

      I would definitely recommend not doing that (php script with direct SQL). It is dangerous, could create inaccuracies in reporting, and is not upgradable.

      At the very least you should use the contact move function rather than direct SQL. Even still, we have not exposed that function because the consequences are not understood by most users.

      When we get the request for "contact_move", we start by asking why they need it. Most of the time, the user doesn't need to move the contact record, but should be creating a new one (sometimes even if it is the same person). If the person has changed organizations, most of the time they have a new email address (I know this doesn't apply if they changed divisions in the same company and each division is an organization in RN CX).

      Scenario:

      Customer John Smith works for Organization WidgetWorks. John changes jobs to FooForgery. If you "move" John from WidgetWorks to FooForgery, now all of the incidents John created when working for WidgetWorks are also moved to FooForgery. This means that WidgetWorks can no longer see those incidents and that FooForgery can. This could be serious depending on what kind of information is in those incidents.

      This is why we have not exposed contact_move in our integration APIs.

      The recommended way to "move" a contact is to get the source contact, copy all of their properties to a new destination contact object, update the source contact's email (if they will be the same) and update the contact. Update the destination contact's organization id and create it.

    • bryan.arndorfer

      I agree that the contact_move function is an API that needs to be used with care, and in specific instances only.  

      We may have a special case. Our integration is a management utility around incidents in the customer portal.  In doing that we understand that a basic limitation imposed on the CP is that in order to manage an incident the contact has to be associated to it in some way. Either directly(on the incident), or indirectly(via an organization).  So we have created a heirarchy of organizations(for permissions and slas) and we assign customer incidents to a specific org, and admins to a specific org.  Admins are easy because they are relatively static, and we know when those are going to be created.  However the customers are creating incidents all day long, and we want to incidents to become available, instantly. 

      Setting the org_id on creation is not feasible at this time, because of all the entry points(CP pages, external integrations, CSV uploads, etc...).  So we would like to grab all the contacts that were recently created(in last few seconds) and "update" or add/move the org_id to/on them.

      Is it potentially possible to get the contact_move function made available from the RN Connect perspective?  If so how do we begin that process? Or do you see another avenue we could pursue?

      If not, is there any future plans for survey creation/completion APIs, so that we could fill in this data?

      Thanks

    • Ryan McCullough

      Your best bet to get the "contact_move" API exposed in RN Connect is to start with the Idea Lab at the top of this page.

      Note that RN Connect Data Integration (CDI) is in a petrified state I believe, meaning no new functionality will be exposed in it, but backward compatibility issues and bugs will still be fixed. If this API is exposed, it would be through either Connect WS or Connect PHP.

      As for Survey APIs, we have had this request before, but have trouble receiving consistent feedback on what is required. Again, I would point you to the Idea Lab for suggestions.

      I would recommend you speak with your CSM (Client Success Manager) about your specific business use case and ask for a best practice. At first glance, it sounds like an external event (EE) is what you want. They can be triggered by a contact_create and execute on every contact insert (or update & delete).