Closed support mail processing

Discussion in 'Using the new Kayako' started by Phil R, Sep 12, 2016.

  1. Phil R

    Phil R Established Member

    I've highlighted one of our use cases as being a closed support model.

    I note the options that will allow auto-suspend messages from unregistered users, but that does not prevent the "Start new conversation" link. Per our recent call, we can make use of the "Header" template to add some logic to only display that link to logged in users.

    However, I am also wondering what happens with mail processing from unregistered users for the following areas.

    1: I assume that new messages from unregistered users are suspended when the option to do so is set?

    2: If a Agent adds somebody to the CC of a case, is the CC user added as a User in Kayako?
    This is a very large problem we are experiencing in v4.

    3a: If the case reporter (customer) adds a CC to an incoming email, how does Kayako handle the CC?
    Does it add them to the CC list automatically?

    3b: If they are added as a CC to the case, and per #2, does Kayako add them as a user in this context?

    4: I am looking through triggers for ways and means to handle incoming email and provide some needed protection. Staff members incorrectly replying to emails, emails from unregistered users. It seems that triggers don't provide any great control here, certainly not even a patch on the mail rules we see in v4.

    For a given set of rules, how can I take specific actions?

    Examples.

    For an unregistered user sending to a@x.com, send auto-responder Q and do not accept the case.

    For a registered user sending to b@x.com and it does not relate to an open case, send auto-responder Q and do not accept the case (we don't current accept new cases via email for most departments, but this may change with v5, but I am building the use case around it being retained and will pull away from it if the business asks)

    For a registered user sending to c@x.com that has not present case open for the topic they are sending. They must have keyword Y in the subject line and a attachment (any attachment, we don't validate content).
    1: If they don't have the keyword in the subject, use the default "type" for the case and assign to a specific case form.
    2: If they do have the keyword but no attachment, dispatch auto-responder and do not accept
    3: If they do have the keyword and attachment, accept and give it a specific type and case form.

    I'm not sure I have
     
  2. Gary McGrath

    Gary McGrath Staff Member

    Hi Phil,

    Following on from the other thread, which options in triggers do you think would help with such cases?

    Gary
     
  3. Phil R

    Phil R Established Member

    There is lies a problem.

    There will be soooo many things we want to do differently in any migration.

    Our current install is an accumulation of inherited work for me. I've slowly worked in flows to make things work reasonably, have had to put off work to make things work properly and completely neglected work around removal / decommissioning others. Each of these may hamper each other (and just how we grew to so many SLAs & notification rules).

    Given this, I can only speak for what we have, not we will actually want. Even one of the samples given in my message, I am looking to purge (this week) from existence.

    I'm hoping to have my requirements internally done soon, at which point we can get the gap analysis done and report back to you.
     

Share This Page