General Functional Discussions for Service

Get Involved. Join the Conversation.


  • Sebastiaan Draaisma

    You could use an escalation rule to close the incident.

    Have the first rule send the response to the sender and within that rule, call a function in which you have an escalation rule that will close the incident 5 minutes later. Please observe that escalations run every 15 minutes and that the incident therefore may be closed up to 15 minutes after your message has been sent.

  • Sebastiaan Draaisma

    I agree with Tushar.

    If you have to use an on-load trigger try to ad additional conditions to it to make it as specific as possible as it will otherwise impact performance

  • Tushar Gupta

    Hi Mohamed,

    The number of workspace rules isn't defined. There are a lot of things to consider like how many tabs / fields / reports the workspace has and also the triggers used in the rules. If the workspace is very complex and you have too many rules then it can slow down the workspace and loading time of the workspace would increase. Try to optimize it as much as possible.


  • Sebastiaan Draaisma

    Do you happen to have an 18B (or earlier) version?

    In 18B, it is not possible to create an interface specific incident archive or purge policy using the Data Lifecycle Management framework. However, starting from 18C, you can create custom Data Lifecycle Policies for incident and contact archive/purge for your business needs.

    How can we use Data Lifecycle Policy to purge (or archive)?

  • Marissa Gonzales

    Hi we recently used Data Lifecycle Management to auto purge/delete incidents.

    I am now interested in using it to purge/delete contacts with no contact us over 3 years.  But when I go to create the rule, the If and then statements are blank and I am unsure how to add any rules.  Are you familiar?

  • Justin

    yeah he shouldnt be responding unless you disable secure update (which i wouldnt recomend), its better if he just logs in and works the incident through the console. You can also put in a business rule that says if an email comes in to the outreach mailbox (which is what sends those notification emails) then do not create incident. 

  • Sebastiaan Draaisma

    Also check that it's not related to MYQ_REOPEN_DEADLINE (this would affect all replies, not just from agents responding to an email created by business rules)

  • Sebastiaan Draaisma

    That is correct and standard behavior. You can change this but it's not something I advice.
    Have a look at the configuration setting EGW_SECURE_UPDATE_MODE
    You would need to change that and use the original incident ref no. in your subject.

    Abetter alternative is to modify the message template and to include a URL to the incident in BUI. This way your agent can change the incident (add an entry, private note, change status etc)

  • Pavol Procka

    I thought Save & Close wouldn't be possible in the Workspace Rules :)

    Should have looked better!


  • Sebastiaan Draaisma

    Hi Pavol

    You can save another click :-)
    If you use a spam button as you stated you can add an additional action to it (Execute an editor command) that will save and close the incident.

  • Pavol Procka

    Thanks all for great suggestions. I agree fully on the part that there should be a Corporate system before Oracle, and we do have this, but I am talking about emails that still come through. As for Barracuda, I do not expect magic from it, but such a basic functionality as to not let through emails from manually blacklisted email addresses should definitely work - if it doesn't I have little trust in any other function within it.

    I believe I am going to stick with Sebastiaan's suggestion because as he pointed out, I need the agents to be able to quickly mark spam. They anyway have to trash those emails when handling them as they do arrive in OSvC. It actually should be able to save them one click :)

    (Currently: 1 click to open Status Menu, 1 click to chose Trashed, 1 click to Save & Close

    New: 1 click on a SPAM button (upon which a Workspace Rule will change Status to Trashed and set the Contact Custom Field "SPAM" to True), 1 click to Save & Close - next time we receive anything from this email address the Business Rule will catch it based on the Custom Field value and stop it from creating an incident.)

    As for the Mailbox filters, I am talking about at least hundreds of email addresses every week which I still would need the agents to mark, so that I can find them and then add to the filter.

    Many Thanks


  • Sebastiaan Draaisma

    Mailbox filters are not ideal either. They are only accessible to admins where a custom field on a workspace allows for easy access to agents dealing with incidents. But I agree that preventing is better than curing. It also depends on the customer and legal compliance. I have government agencies as clients that do not want to filter anything away as they need to comply with local law but they do use a custom field.

  • Mig Ponce
    • posted via email reply June 19, 2019
    • Permalink
    I think it's common to have external (corporate) spam filtering before anything even gets through to Oracle. So Oracle ends up being a second line of defense, and whatever Spam filtering they use. I don't think Barracuda has been discontinued, but it's possible that their own algorithms may have updated. Containing spam is a never-ending and constantly changing thing so I'm not surprised of previously blacklisted stuff gets through, though certainly it shouldn't happen.
    I think business rules is *not* the ideal way, because they have to churn every time an incident gets into the system. Granted, the system can handle a huge volume of business rule processing. But it still has to go through potentially every rule until it finds a match, then has to deal with either setting statuses, deleting, not-creating-incident, or whatever the rule action needs to do. It's an unnecessary load on the server, even if small. And the only way this would be effective is to block a specific address that is a repeat offender. Spam generators can get around this easily.
    It's much better to block before it reaches the rules. One way to do that is to add addresses or other criteria to the individual mailbox filters. (Mailboxes > Incoming Email > Discard filters.) Here's where you can list specific addresses, headers, etc. A good use case for this is if you need to block certain auto-reply addresses, like ''. What will happen then is that "we've received your message" email of theirs will hit the mailbox, get caught by the discard filter, and the story ends. No need to trigger the rules and go down the list evaluating until the correct one matches. This too would only really work for specific repeat-offender addresses that you want to block but that aren't spam pe se.
    I'd say that mailbox filters are better than business rules, pretty much always, unless there is some reason you need to do an additional action upon it. For spam messages, I can't imagine when this would be the case.
    Summing it up, the layers of defense should be:
    Corporate, external to Oracle > Oracle spam handling (e.g. Barracuda) > mailbox filters > business rules (last resort or if additional action is needed on the messages).
  • Sebastiaan Draaisma

    I have said goodbye to Baracuda a long time ago. We do filtering through business rules (regex on thread, header, email and subject) and jst give them a specific status which allows us to quickly adjust filters (BR) and use the rule log to see which one got triggered. We also have a more permanent one (custom field menu type for contact)

    1. Never spam
    2. Always spam
    3. Filter

    Default is filter which would make incidents from this contact go through the filter.

  • Neil

    I had the same issue. None of the blacklist addresses I put in picked anything up. I had to resort to a couple of business rules.

    Sometimes I get quarantine emails from it though, but nothing to do with the rules I put in just the odd email if flags itself.

    I guess if there were no other option you could write a CPM to delete/categorise incoming emails and use a custom object to store a blacklist. That seems like there should be a better solution though with less effort.