View Only

Discussion Thread View
  • 1.  Add Records on the fly. Status J

    Posted 11-21-2017 15:23
    Hi, I made a new load (in Excel) for a contact list with a new column called STATUS with a J for all the records. After populating the Contact list via the Administrator, I verify in Database that records are in STATUS=J but the JIT table is empty. (Priority dialing is enabled and the campaign is ON) What is the right way to populate a contact list with records on the fly to be dialed immediately (CIC2016R4)? Thanks

  • 2.  RE: Add Records on the fly. Status J

    Posted 11-21-2017 22:00
    That should do it! Open your database in Management Studio and try to do a single record insert (with status J) and see if that populates the JIT table. Have a look at your contact list and see if there is a trigger configured on it for Inserts. Don't forget that sometimes JIT can be a little TOO good and it may have dialed the numbers and given up before you got to look at the table! You could also try extending the period between scans of the table to reduce this likelihood.

  • 3.  RE: Add Records on the fly. Status J

    Posted 11-23-2017 10:37
    Hi Paul, thanks for the answer. As you suggested, I tried the insert directly in the CL. The trigger, i3_jitt_CL_xxx, showed up and the JIT table was populated correctly. After several tries via Administrator, the records were loaded in "J" status but the JIT table did not populate

  • 4.  RE: Add Records on the fly. Status J

    Posted 11-24-2017 11:05
    Aha! You didn’t mention in your original post that you were uploading via IA! (The devil is always in the detail!) In my experience, the trigger doesn’t fire when using IA like this. I have no idea why and have never investigated it further. I would suggest reporting it to Support to get it properly looked in to and, assuming it’s a real undocumented feature, flagged for fixing. Most of the people I know who use JIT dialing, do so along with inserting directly into the table, usually connected with the back end to a web page or similar. This might be why the concern hasn’t been raised before. I am traveling at the moment, but as soon as I get near a computer, I will try to investigate a bit more for you. In the meantime, I know it’s cold comfort, but it isn’t just you! HTH

  • 5.  RE: Add Records on the fly. Status J

    Posted 11-27-2017 16:57
    Yep, via IA. I used this way a lot in ININ v3. I am trying to contact support and find out if there is an issue or this is not an option anymore in V4. Thanks

  • 6.  RE: Add Records on the fly. Status J

    Posted 12-04-2017 16:41
    I don't know if you ever got a response from Support, but I took a quick look at the documentation and it does state "To dial new records inserted by this wizard, a recycle is required." It then directs to the priority dialing documentation, but to me this indicates that inserting as priority through the wizard isn't supported. Because the priority feature works by using a trigger on the call list table, certain actions bypass the functionality, primarily doing bulk inserts, which bypass triggers. My guess would be that the contact list import wizard is doing a bulk insert. I can't speak to be behavior changing from 3.0 to 4.0+, but very possible if they changed the way the import is done (e.g., started using bulk inserts for performance improvements).

  • 7.  RE: Add Records on the fly. Status J

    Posted 02-14-2018 15:24
    Sean, you are both correct and incorrect! Ordinarily, when you muck around with the contact list (which includes changing Sort Order or Filters) then a recycle is required for the changes to be picked up. This is down to the way the Recycle Table works. In essence, it is an index of all the callable records in the order they are to be called. One of the (main) things a recycle does is to repopulate that table. As a result, if you add records to the Contact List, they won't be referenced in the Recycle Table and therefore won't be called until after the next recycle. (Since both the Filter and the Sort are also part of the process that populates the Recycle Table, the effects of changing them are also not seen until the next recycle.) That is the "You are correct" part ;) JIT / Priority dialing was created, in part, to avoid this issue. There is a second table (the JIT table) which performs a similar function to the Recycle Table, however it contains records that have been inserted with a status of "J" and, rather than relying on a recycle, it is populated by a DB trigger that is executed whenever records are inserted and which is checked periodically (the frequency can be specified in the campaign settings) and anything found there is dialed ahead of anything in the Recycle Table. As a result, no recycle is required for the records to be detected. That is the "You are incorrect" part :D The upshot of this is that JIT / Priority dialing relies on triggers set for inserts. (As an aside, it is worth mentioning that changing an existing record's status to "J" will not work since the trigger is only on an insert. I don't know with 100% certainty, but I am 99.9% sure that this is due to performance. Dialer itself doesn't insert into the table much (if at all!) but it does update it. A LOT. Having a trigger on an update would probably destroy the DB server performance.) As you say, it all depends upon how the records are being inserted as to whether the trigger gets fired. I wasn't aware that the bulk insert avoided the trigger, but now I think about it, that makes complete sense. Since such triggers fire on a "per record" basis, if you inserted, say, 10000 records then that's 10000 executions and possible performance issues! As I mentioned previously, from what I have seen, most people using JIT are doing so as part of a system that has a back-end that inserts odd records (say, from a web page) so this isn't an issue. If it is causing problems (as in this case) then Support (and then Development) need to know. It could be as simple as having a second SP that runs after a bulk insert that checks all the new records for status of "J" and updates the JIT table accordingly. This would probably need to be an option, though, since for those folks who are updating the contact table with large record sets through IA and NOT expecting JIT, you wouldn't want to hit performance! (A classic case of you can please some of the people some of the time...) Anyway, the upshot of all this is that it looks like the system is behaving as expected / designed and the OP will need to investigate other ways to achieve their specific requirement.

Need Help finding something?

Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources