• Wouter Willemse

    Agree, it's very poor UI as it is, hard to discover its functionality.

  • Wouter Willemse

    If this is still an open request, the functionality you'd need to generate an incident response, and send out an attachment with the incident response: it's available with the 18B release in the SOAP and REST API. In older versions, the functionality to send an Incident Response was not available in the REST API, only in the SOAP API, but without support for sending out attachments (meaning: you can attach files to the incident, but they will not be included in the mail that is sent out).

    So if you need this functionality (like we do :-) ), it's worth upgrading to the current latest version for it.

  • Wouter Willemse

    Referring to the bold part, the only thing I tried to say there is that you can leverage the existing session of the console to authenticate access to the APIs; so you do not need to store usernames and passwords in code or otherwise to connect to the API.

    There is some access to data without needing the SOAP API: only to the open record in the workspace (for add-ins running in a workspace context); the IRecordContext interface exposes it via the method GetWorkspaceRecord. You do have to cast it yourself to the "correct" interface like IAnswer or IIncident, for example:

    IIncident curInc = (IIncident)_recordCtx.GetWorkspaceRecord(WorkspaceRecordType.Incident);

    You can change values of it, and refresh the workspace to see those changes, but they will only persist when the user actually saves the record in the workspace. And for anything more complex, or interactions with other objects, you will need to use one of the APIs.

    Not sure whether this is what you meant, though?

  • Wouter Willemse

    The add-in framework does contain a "shortcut" to instantiate a SOAP-connection, leveraging the connected agent account directly (AddInGlobalContext.PrepareConnectSession). So it seems to favour the SOAP API, but in reality the REST API works equally well. You can also use the connected agent account to authenticate (use the value AddinGlobalContext.SessionId for Session authentication in the REST API), so in reality there PrepareConnectSession method doesn't give a huge benefit.

    If needed, you can even use libraries like RestSharp to simplify your code to interact with the REST API. Works very well.


    The SOAP API, however, does allow working with custom objects and custom fields, but (in my view) it leads to very verbose code. There is a section on it in the Connect Webservices for SOAP documentation (How do I -> Working with Custom Objects).

  • Wouter Willemse

    I know this thread is quite old, so my answer is probably royally late. But since this thread seems to be the only information I could find on this topic, I think sharing my finding might be useful for others.

    When I set the localization directly in the CreateControl method of the Workspace...Factory class, it actually works; in below codesnippet, I set the CultureInfo object from the desktop agent language:

    public IWorkspaceRibbonButton CreateControl(bool inDesignMode, IRecordContext RecordContext)
        var serverConfiguration = GetConfiguration(this);
        System.Threading.Thread.CurrentThread.CurrentUICulture = Classes.Helper.GetCultureInfoFromConsole(AddinGlobalContext.LanguageId);


    Setting the CurrentUICulture in the form-class itself (like you probably would do in a normal winform application) does not work, and leaves the localization at the default language. Of course, you do need to copy the folder for the compiled resource files for each language to the Add-In folder, and hence to deploy it, you will need to upload the addin as a ZIP file. If you use the normal post-build events to copy the addin to %USERPROFILE%\RightNowDev\AddIns, these folders will not be included, so you need to do so manually (for debugging/testing).

    The above is done on Aug. 17 release, with .NET Framework 4.6.2.

  • Wouter Willemse

    Is there an idea already when this development might make it into production? Is it expected to ship with one of the upcoming releases (18B, 18C) ?

    Thanks again,


  • Wouter Willemse

    Frankly, I think you can achieve this with Rules - if you have multiple mailboxes set up, you can change the mailbox for the incident (and this mailbox will appear as the sender). But blocking responses to the autoresponders means customer could not respond to the incident, so you'd have to carefully set up your rules to get that behaviuour (again, using mailboxes as conditions in your rules, it should be able to achieve it, but it sounds tricky and you have to ask yourself whether it's customer friendly to block responses if sent to a specific email address). 

    But maybe your business case is different? Maybe it would help describing the case a bit further

  • Wouter Willemse

    It's amazing to me the application still doesn't implement this, or expose such functionality in some way that you can customise your search report to take values from the incident editor (category, product, language). Even if you still want the agent to have some flexibility in searching by manually selecting some of these parameters, by default the values for product and category at least should be pre-set to those of the incident open.


    In our setup, The smart assistant does not do the same thing, as it will only show public available answers that see a lot of visits, and exclude the knowledge that is only available internally since it will never reach the same rating as public content (far less visits for starters).


    So, frankly, I do not see this as "nice to have" but rather as how the application should behave. That it has not been addressed since 2011 is frankly a rather scary idea.

  • Wouter Willemse

    Thanks, this is great news!

  • Wouter Willemse

    We'd certainly have use cases for this (the ability to base rules on there being an attachment, and if yes, the size and filetype of the attachment). It could automatically kickstart document validation procedures, for example, or set useful autoresponders if an expected attachment (type) is not found - and reduce manual efforts from agents.


    It's a pity there are a fair number of ideas like this which would strengthen the core functionality of the product that are lingering here seemingly unnoticed for years. I'd love to see a release, or 2-3 releases, focus on improving the core elements  of the product, instead of offering more features.

  • Wouter Willemse


    The idea to keep people orignally on CC on the incident updated this way is a great idea, I'll certainly keep that in mind.

    Indeed a lot could be done with a CPM, but for sure inclusion in workspace rules would be a lot more flexible and easier to manage. I think in order to deal with the scenarios we have (multiple countries with different procedures and processes), using CPMs I would certainly need a custom field to trigger the correct action, making the CPM a lot more complicated and fragile - not undoable, but not ideal, and in case of issues things become progressively harder to troubleshoot as well.


  • Wouter Willemse

    I think this functionality suggested should be integral part of what is recommended in this idea: Since both are marked as under consideration, I do hope there will be some sort of update on where this stands.

  • Wouter Willemse

    From the original post, options #1 and #2 would still be very valuable, as it happens often enough business processes require by default a number of people on CC or BCC to alert them, and there is currently no way to automate this. I think such scenario is very common for most users of OSvC, and most business users look at the product to deliver value via these time-saving automations (plus reduce human error), so being able to deliver just that actually help acceptation a lot.

  • Wouter Willemse

    Is there any status update? This has been "under consideration" for a long while now, and from the reactions and the number of likes, it is clearly a much needed feature (which frankly cannot be that hard to implement technically). I know there are alternative approaches available (for example incident collaboration), but a clear, native solution as described in this idea would by far be the best solution.

    So, if it's under consideration - what's holding it back, and how can we help make the case? If it's not considered, why not and how does Oracle envision we deal with this instead?

  • Wouter Willemse

    Maybe I have not explained well how I meant the implementation:

    1. You create a seperate workspace where the default channel is set to Phone, and which only shows the fields needed for that situation. So, a dedicated workspace only for these phonecall incidents. You can set the default thread type and channel type in the properties of the Rich Incident Edit Control (select, click the tab 'Design');

    2. Use create the script in the workflow to distinguish between new normal or new phone incidents. Based on the outcome of this script, you either load your normal workspace, or the phone workspace you made in step 1.

    So the point is NOT to set the value of the thread type/channel, but instead make choices between workspaces that have the defaults set up correctly.