• Charlie Mopps

    Just stumbled across this, sorry for the late reply. Rightnows Analytics administration leaves a lot to be desired. We've worked around it though. We name every report as follows:

    ReportName_ReportID : Example - My_Incidents_123456

    We do the same for workspaces, navsets, everything...

    We also name all of our rules, mailboxes, etc, as follows:

    1000- Firstrule


    Etc... so we can figure out which is which when we get errors. They're numbered by hundreds or thousands so we have room to fit in new rules between if we need to.


    Good luck

  • Charlie Mopps

    1. No... Rightnow runs on MySQL but you basically have no access to the tables.

    2. RightNow had an ODBC connection but they are depricating that to force us into using the SOAP API. You can use that but it requrires writing code in C# or Java and they written their own version of SQL called ROQL which is horrible and has a limit of 10k rows. Creates updates and deletes can only be done 100 records at a time so if you have a lot it will take a long time. I just got done with a 5.6 million record update and it took my code 3 days to complete the task.


    Good luck.

  • Charlie Mopps

    That depends... how confortable are you with C#?

    You could take your existing Accounts as a recordset and use the SOAP api to create the accounts. But I do not think you can properly set the passwords from there. You'll have to research that part, because I'm just not sure.


    As far as any normal user import method, there is none. Most administrative tasks like this are all GUI based and extreamly tedious. Depending on how many users you have (we have LOTS) it may be worth your while to write a SOAP integration to help manage your users. Rightnows management tools are... difficult.

    Oh, and before you get going, let me give you some tips to keep in mind. We didn't know a lot of this when we setup our system and regret much now:

    1. Never make rules that reffer to a specific user Account. i.e. if user is "john smith" do something... When that user later leaves, you'll be unable to delete their account because of the rule dependancy. But if you have lots of rules, you'll never find that one again. And there's no way to search or filter them so...
    2. build your reports as if you have tens of millions of rows of data in your tables going back years. If you don't they will run now, but will stop working years from now when you have lots of data. The reports have a limit of 2 million rows. Adjust your filters so users can not querry more than that. Always put manditory start and stop dates, etc... Otherwise you'll have people putting critical reports into deffered status left and right and you'll spend a lot of administrative time fixing them.
    3. Do not make a new profile for 1 person. i.e. "Judy needs this 1 extra thing" If you do, when Judys team adds a new field you will forget about her and she will not have it. Also, you'll likely have dozens of Judys all over the place. It's better to say "how about we add that feature for everyone and you tell all those other people to ignore it" If it's not sensitive data, don't limit access to it at the expense of administrative overhead.
    4. Don't delete records. Ever. Rightnow does not handle it well. Often other records will get deleted along with it (if you delete a contact, all incidents under that contact get deleted) or worse, you can lock the database and have to open a ticket for them to unlock it. It's much better to just put the record in a disabled state and ignore it for safetys sake.
    5. If you have deparntments that will be building integrations that use the API, give each new project its own API login and keep track of it. It's VERY important to know every integration you have when it comes time to upgrade. Rightnow tends to depricate things left and right and break integrations. If there are integrations you don't know about, you'll not test them... and then you'll have outages.
    6. workflows are your friend. Learn and use them well.
      • First create 1 workflow for each record type. For example "the incident workflow" and give this to everyone.
      • This primary workflow leads to your real workflow, all it does is direct the users to the primary one they'll use.
      • Then, when you have a project where you need to replace their workflow with a new one, rather than updating 100 profiles with the new workspace/flow, you just swap out where this single flow points. This also allows you to build the new flow in production ahead of time and test it. Rightnow does not have a test environment.
      • Also, once inside the "Real" secondary workflow, use that to direct users to the correct flow they should be using. Again, modifying where they go from their profiles is tedius. If you can get the flow to take care of it, maintaining the system is much easier.
    7. Add the report ID to the name of every report you create. Instead of "My Incidents" call it "My Incidents - 254896" Your users will have a very hard time telling you which report they are talking about... and when they say the name is "My Incidents" and you do a search for it... you'll find there are 10+ reports by that name. Then you try and get the user to find the report ID, which for some god awful reason is called AP_ID or something... they'll never find it. Just put the report ID in the name and be done with it. It'll make things a lot simpler for you in the end.

    I'm sure I'll think of more later, but hopefully this will be of help to you.


  • Charlie Mopps

    We checked with our teams that use this and they thought it already worked the way you plan to change it. So I guess they consider the fact that it doesn't, as a bug. 

  • Charlie Mopps

    Does your solution accept standard SQL?
    Basically real SQL and not ROQL?
    Are all of the tables available?
    Is the data up-to-date? If not, how out of date will it be? Hours? days?



  • Charlie Mopps

    Now I have to read up on what SLA instances are. Thanks for the tip.

  • Charlie Mopps

    I'm going to save you some time and heartache and just tell you now, don't even try it. The limit on the reference number is the least of your concerns.

    Oracle Service Cloud / Rightnow has some pretty strict restrictions on what can be returned in any analytics call (reports) if you were to import >100,000 records at any one time, and then later wrote a report that was, for example, supposed to show you all tickets for a day, or queues by day, etc... that report would never run because of your large import. Even worse, there are a lot of internal canned reports that you cannot edit that might break as well.

    Which contact are you going to attach to these incidents? If you assign the same contact to all 1 million of them, and then later update that contact, you'll find out the hard way about Parent>Child chain updates. Updating that 1 contact in the wrong way (like changing their Org_id) will result in all 1 million incidents updating simultaneously. Your entire site will come to a screeching halt.

    We've found out the hard way that large records updates are a no-no. We actually have a company policy that restricts record updates to <10,000 records per hour. We actually try and keep the number below 2000 per hour if we can.


  • Charlie Mopps

    MB said:


    I had to hard code Created and Closed but am now being asked for a way to allow a date range to be entered for the cases created and cases closed

    I imported your report def but not sure if I understood it clearly especially what you meant by "hardcode created and closed...". An example would help 



    View original

    You replied to the wrong post. JLFolkman was the one that gave you the report ;-)

  • Charlie Mopps


    You can do it on a workspace though.

  • Charlie Mopps

    First, this will give you "Day of the year": Date_format(incidents.created,'%j')

    the rest is just some nested If statements and math. I don't normally cacluate this sort of date but if it's every 91 days (until the last quarter) then this will work. You have to convert the day_of_the_year to an integer before the compare, it wont cast itself.


    IF(to_number(Date_format(incidents.created,'%j')) < 92,
        'Quarter 1',
        IF(to_number(Date_format(incidents.created,'%j')) < 183,
        'Quarter 2',
            IF(to_number(Date_format(incidents.created,'%j')) < 274,
            'Quarter 3',
                'Quarter 4'

  • Charlie Mopps

    Create 2 reports.

    First one called: Search by Model and Serial <--- make both fields required on this one

    Duplicate the report, REMOVE the filters from that one.

    To search by model and serial they have to open the first, to search on the second, they're not allowed to search by that at all. You can the same effect.

  • Charlie Mopps

    Leonardo, I'm glad it helped!

    You can read about the WSDL's polymorphic nature in the Connect webservice documentation:

    Start with the section: Connect Web services>Operational Behavior>Operational Overview>Polymorphic Behavior
    There's quite a bit to go over there...


    He's not using a programming language. He's trying to use the WSDL "Natively"? Not sure if that's the correct term. What you're talking about are programming languages that have Objects that automatically generate/translate the XML for you. In C# you call the method Create.Contacts.???? etc... and that dynamically creates the XML for you and sends it. Likewise, when Rightnow makes changes to the API, those methods handle those changes on the fly. Where-as Leonardo’s integration here will break until he can update his XML (hence my warning earlier)

    You're talking about "Enterprise languages" that have Soap toolkits... well, that's true for the 2 you support (C# and Java). But in reality most don't work with Rightnows WSDL at all (trust me, I've tried quite a few) And, really, most integrations don't use any language at all. For example, we use Siebel, another Oracle application. You open Siebel, click a few links to create a new integration, drop in the WSDL URL and your credentials in... then you can literally drag and drop fields from Siebel to your integration partner. Ticket# = Incident.ID, etc...

    With Rightnows Polymorphic WSDL, you CANNOT do this. The only way you can get the integration to work is to modify the transaction manually and change the XML by hand like Leonardo is doing here. You have to tell Siebel that, to create an incident, you send this XML… and you put X field into Y variable in that XML string. It’s quite labor intensive. We’ve hundreds of different software packages here, most of them Oracle and Rightnows WSDL doesn’t work with any of them. In every case we’ve had to rig the XML just like Leonardo. For every other application we use, you simply drop in the WSDL, and drag and drop fields to each other in a gui and away it goes.

    Don’t get me wrong, this polymorphic behavior has lots of benefits. It’s just that none of those benefits are used by any application I’ve ever seen. Rightnows chosen a little used WSDL format that has theoretical advantages that are rarely, if ever, used in the real world. I do hope that in the future RightNow sees the light and issues and industry standard xsd:Choice WSDL. You’d have a lot fewer support questions in this forum I’d bet.


    To read more on the topic, go here:


  • Charlie Mopps

    Well, there's documentation for the entire API:

    Just replace the date in there with whichever date of the version of Rightnow you're using.

    There's some stuff in there about ROQL but you've got to wing it with a lot of it. The most help you'll get is in these forums.

  • Charlie Mopps

    But you'll find no help for PHP.  I've got a collegue that's basically a genious that managed to get the API to work with VBA so he could pull data using excell. But like I said, he's a genious. The only real documentation they have is for Java and Visual Studio. Even that isn't the best.

    The SOAP interface is good at doing small updates and data request. So if you're just making a webpage to create tickets or retrieve records, it'll work well for that. But if you want to make large updates or sync and outside database you're looking at a large project and will run into some very annoying and often unnessisary obsticals.

    Also, despite what they say the SOAP UI is not usually backward compatible. We've been using it through 2 upgrades now and in both cases we had to make major code revisions because they eliminated Overload meathods that had previously been required. i.e. In the previous version we HAD to use 4 opperators, and in the new version it would no longer accept 4. Rather than just ignoring the extra fields that had been required in the past (bset practice) the meathod errored out instead. Which ensured our integrations would fail. I still don't understand why they did that.

    There is a PHP connect API but that's made to be used from the CP pages (The website) Inside the application you can use the "webpage" boject and include a webpage... then on that page you can use Javascript and PHP to access data that's on the record the agents currently editing. But you'll only have access to that particular record unless you make a soap call. Again, you'll be on your own there. There's no support that I know of for PHP SOAP access. Though, if you're good enough at PHP I'm sure you could figure it out.

  • Charlie Mopps

    I just realize I can attach files... here you go. It's not much.

    They keep sending me these 3 links over and over again:

    And of course, there is the section in the manual that pretty much tells you the same thing.

    Then I found these 2 docuemnts. One walks you through how to setup a particular SSO client... but the data the enter during the example is mostly bogus.

    Lastly there's a PDF of a power point presentation from someone that no longer works at rightnow so you can't ask her for help. It has no naration along with it so... it's not very helpful either.