CA Service Management

We would like to track when a user type changes to Analyst access type or from Analyst access_type back to non analyst access.  I would like it to work like Prev_status versus status.

Service Desk works very differently dependent on access type; but I can not figure out how to trigger actions when access_type changes.   Any ideas on a work around or does someone have a procedure to create a attribute?

Would like to know some of the inventive ideas being used by the community.

Hi Dana,

This is a great question - I did some quick research, and there is nothing available out of the box for this, however I did locate a custom way of doing this in my research here.  I cannot say that it will work for sure as I have not personally tested it, but you are more than welcome to test this in a test environment to see if it works for you.

Here are the steps:

1. Go to '$NX_ROOT\samples\call_mgt\' and open the 'audlog_site.mod' file with any text editor, e.g. Notepad++ or Notepad

2. Copy the code section that relates to contact:

// Add to Contact object.
OBJECT cnt {
TRIGGERS {
// log field changes for custom attributes
POST_CI audit_fields_site(persistent_id, audit_userid, combo_name, attr, attr, ...) 51
FILTER( EVENT("UPDATE(NX_AUDIT_UPD)") );
};
};

3. Paste the copied code in a new file, say: zcnt_audlog_site.mod and save the file in the following path: '$NX_ROOT\site\mods\majic

4. Edit the code in the new file (zcnt_audlog_site.mod) to add the contact fields you want to audit and save it:

// Add to Contact object.
OBJECT cnt {
TRIGGERS {
// log field changes for custom attributes
POST_CI audit_fields_site(persistent_id, audit_userid, combo_name,
access_type, dept) 51
FILTER( EVENT("UPDATE(NX_AUDIT_UPD)") );
};
};

5. Restart the ServiceDesk service

6. Once the services are restarted, changes made to the contact's 'Access Type' and 'Department' should now appear in the 'Audit Log List'.

Hope this helps.

Jon I.

Jon,

Thanks for finding this.  I will give this try and let you know from my test system.

Dana Calderwood| App Sys Ana| Technology Services Organization

Presbyterian Healthcare Services

505-923-5029 (Office)

dcalderwo@phs.org

HI,

in fact we have this customization  in place for years with no problem at all.

You just need to keep an eye on the audit_log table growth and purge when required as best practice anyway.

/J

Hi,

Can you provide a use case?  It would be helpful to know what action you want triggered when Access Type changes.

Grant,

When new employees are onboarded from our HR system they are normally setup as an employee.  If for any reason someone is changed to Analyst, training notifications and other processes need to kick off.  If they are going from analyst to employee after a transfer a different process needs to take place. There are several different scenerios, but in order to make the correct decision we need to know what role they are coming from and going to.

Hope this explains it.

Thank you,

Dana

Do you use CA Process Automation in your environment?  You could create a activity notification which is triggered when Access Type changes that can fire off a PAM process.  This would allow you to send notification and kick off other processes via PAM.

Grant we do have PAM, and I am sure this would work.  PAM is a new beast for me and I was trying to avoid; she is powerful so may end up there.

Thanks

Dana

Another possibility would be to use a trigger to capture the 'previous' value in a new field in the contact record (unlike 'cr' and 'chg' there are no spare fields in 'cnt' so you'll have to add one).  You can then use the new field in an Activity Notification event that fires when Access Type changes.  When a trigger fires, the spel function it calls is passed a triplet of values for each attribute that is passed in the call - containing the attribute name, the old value and the new value.

So in a PRE_VALIDATE trigger like this, which will fire when the access type is changed but before changes are saved to the database:

OBJECT cnt {
    TRIGGERS {

        PRE_VALIDATE  zcntCatchAccType(access_type) 99
            FILTER( access_type { } );
    } ;
} ;

OBJECT cnt {
    FACTORY {
        METHODS {
            zcntCatchAccType(string);
            } ;
        } ;
    } ;

...the function 'zcntCatchAccType' will be passed an array containing three strings, of which the second will be the 'old' access type.  Assuming that you have created a new field 'zPrevAccType' of type INT in the 'cnt' object, probably all the function needs to do is this:

cnt::zcntCatchAccType(...)
{
   int zOldAccTyp;

   zOldAccTyp = (int)argv[2];

   this.zPrevAccType = zOldAccTyp;

}

Hope that helps...

Regards,

James

James,

This is great, I knew you guys could come up with something. I am fairly new with service desk and appreciate this quick response.

Thank you,

Dana

You are most welcome.  One of the great strengths of this community is the attention it gets from all points of the compass.

Definitely going to try this.