11 Replies Latest reply on Mar 6, 2018 12:43 PM by Nicolas Roome

    Update LDAP Contact from Ticket

    Anthony Guthrie

      Greetings,

       

      I have a (hopefully) quick question regarding updating LDAP contacts. I read a couple other threads but they didn't quite seems to apply here. Not sure if this active defect pertains to my situation:

      Address BookDRZNZ-2193The updated information of a contact from an external address book such as LDAP is not updated in the FootPrints application.2017-11-30

       

      Running version 12.1.06 and hopefully soon moving to 12.1.08.

       

      The issue I'm having is that I want agents to be able to update contact information from within an Incident ticket. I have a lookup field on my Incident form that pulls up customer information. There is also an After Save rule that links the Contact to the Incident, which is also working. However, I added a field to Contact called 'Building' that is not pulled via LDAP. I would like agents to be able to update this field on an Incident ticket, and have it update the Contact record. That way, next time a ticket is opened for the customer, their Building info will be pulled up automatically. If it ever changes again, the agents can just update it while they're putting in a ticket.

       

      What's happening right now is I can pull the info into the Incident, but when the Incident is saved, none of the fields in the Contact are updated... Also for some reason, the 'building' field on the Contact gets blanked out (I populated this field manually on the database, then after saving the Incident that had a link to the contact, this field became blank on the database.).

       

      Here's screenshots of the configuration:

       

       

      Address Book mapping for Contact to LDAP.

       

      Incident lookup fields.

      From the Incident form, the contact info is successfully populated, and after saving, linked to the ticket.

      However, entering a value for 'building' only updates the Incident, not the contact record.

       

      Any input would be greatly appreciated.

       

      Thanks!

        • 1. Re: Update LDAP Contact from Ticket
          Don Cholish

          There is no way to write to LDAP.  The integration only is 1 direction.

          • 2. Re: Update LDAP Contact from Ticket
            Mohammad Al Taj

            Don......It's good idea to make it 2 direction with LDAP and Dynamic SQL .

            • 3. Re: Update LDAP Contact from Ticket
              Anthony Guthrie

              Now on version 12.1.08.001

               

              I don't need to update LDAP, but rather the FP address book database. I just set up again from scratch and am still having the same issue.

               

              1. Added a field to the Contact record type called 'Building' - this is not mapped to LDAP.

              2. Verified that the newly created field 'building' was added to the FP address book database table.

              3. Created a data link field in my ticket form to the FP address book table on the new 'building' field.

               

              Now if I manually update the 'building' field directly on the database and then create a ticket, that value successfully pulls from the db to the ticket, so I know the link is working. Also, when saving the ticket, the associated contact successfully links to the ticket as expected.

               

              The only issue is upon saving the ticket. The linked Contact is not updated from the ticket with a new value for 'building'. If a new ticket is opened for the same Contact, even though the 'building' was changed in a previous ticket, the new ticket still pulls in the old value because the Contact was never updated.

               

              Am I missing something in the configuration or is this an issue with the application? Maybe I need an address book that is not linked to LDAP, and just run an import of users every once in a while?

              1 of 1 people found this helpful
              • 4. Re: Update LDAP Contact from Ticket
                Cristy Castano

                Anthony,

                 

                From my experience and understanding from BMC, the address book you have is configured as an LDAP/AD address book; not a FP address book.That is the main issue you are having; since its considered an LDAP address book and its one direction only, you cannot write back into the address book - even if you have a field created there that is not 'mapped' to an AD attribute.

                • 5. Re: Update LDAP Contact from Ticket
                  Nicolas Roome

                  I think I understand what you're trying to do.. Basically have a field in your address book not tied to LDAP correct? I don't believe this is supported.

                  • 6. Re: Update LDAP Contact from Ticket
                    Anthony Guthrie

                    Yes, a field separate from LDAP is what I wanted to create.

                    I ended up creating a new address book and imported the contacts from a csv that was generated with an LDAP query (Powershell). Since it's an internal address book, I am able to edit the contacts and update any field I need.

                     

                    Has anybody else done it this way, or is there a better way to go about it?

                    • 7. Re: Update LDAP Contact from Ticket
                      Nicolas Roome

                      Sounds like the goal is to track or change data without touching LDAP right?

                      • 8. Re: Update LDAP Contact from Ticket
                        Anthony Guthrie

                        Yup. Our AD doesn't have information on the contacts' location, so I wanted to be able to track that separately in Footprints. Down the road there may be additional fields we'll want to add to the contacts as well.

                        • 9. Re: Update LDAP Contact from Ticket
                          Nicolas Roome

                          You could create an item in a container called 'Location', create a record for each location, then link contacts to that location record. If locations are generic enough. Such as city, building, etc. But if there's going to be hundreds of possible locations that might not be worth it.

                           

                          Long shot but any chance your AD team can put it in AD?

                          • 10. Re: Update LDAP Contact from Ticket
                            Anthony Guthrie

                            Thanks for that idea, that might be possible since we don't really have many locations. We probably won't be adding any fields to AD if it can be helped, even though I think a location attribute would be helpful.

                            • 11. Re: Update LDAP Contact from Ticket
                              Nicolas Roome

                              Anthony Guthrie wrote:

                               

                              [...]We probably won't be adding any fields to AD if it can be helped[...]

                              This is something I hear far too often, and usually without any, what I call, valid, reason.

                               

                              Some of what I've heard so far:

                               

                              1) Microsoft wont support us if we have custom attributes. Really? I highly doubt that. Kind of a lame reason either way.

                              2) Our AD guys don't know how to create custom attributes. They can learn. Heck I learned how just watching Youtube videos.

                              3) We don't want to manage this information in AD, it's too time consuming. Really? You think it'll be less time consuming to manage it in another system like FootPrints? If it's too time consuming for AD, it's too time consuming for anything else really.

                              4) We don't want to manage this information in AD, it's not relevant to AD. Well if AD is your single source of truth then the info belongs there! Or not at all.

                              5) We don't want AD to be our single source of truth. Why? Fair enough.. then don't integrate your ITSM tool with AD!

                               

                              /2cents