Answers.Body: <p>Another option to explore is if CiviRules has a 'create case' capability that could be triggered from creating an Activity, which itself had been created by inbound email</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-20T22:39:25.433Z
Answers.Text: Unfortunately CiviRules lacked the necessary conditions and triggers.  I added some details in an edit to my original question.
Answers.UserDisplayName: richardsplayground
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-21T02:26:21.687Z
Answers.Text: Then I would think the solution is an extension that would eg work on basis that an email to email address X should trigger a new case, assign to default Coordinator etc if no #caseid is in the subject. doesn't sound like a big job
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-21T02:27:35.470Z
Answers.Text: also did you read this? https://civicrm.org/blog/dahndy/leveraging-civicrm-email-to-activity-processing-in-gmail in case it adds any new thoughts
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-21T02:59:05.570Z
Answers.Text: fyi we did some improvements to Inbound Email so #caseid works in case that gives you some ideas: https://civicrm.org/blog/petednz/improvements-to-inbound-emails-to-cases-in-4730
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-21T02:59:28.537Z
Answers.Text: oh. sorry that was to core not via an extension
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-19T05:20:29.260Z
Answers.LastActivityDate: 2018-03-19T05:20:29.260Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>Our organization has grown past the point where one person can handle the inbound e-mail from our members.  I'm looking for best practices from the community on how to handle this.</p>
  
  <p>We don't want to give all of our staff access directly to the e-mail account.  As staff come and go, we would have to connstantly change the password to that account.  Also, giving everyone direct access to the account would require a tagging system to know who is handling what message.  This seems less than ideal.</p>
  
  <p>We could adopt a ticketing system, either something like osTicket or something like Zendesk.  But I think it would be nice to have all of our interactions with our members in one clear place.  After all, isn't that what a CRM is supposed to do for you?</p>
  
  <p>I looked at CiviCase and at first glance it appears to be exactly right.  But for some reason <a href="https://civicrm.stackexchange.com/questions/24164/how-do-i-automatically-create-a-case-on-inbound-email">out of the box CiviCRM does not create a new case for each new inbound e-mail</a>.  Discovering this got me thinking that perhaps opening a case for each inbound e-mail is not the right approach?</p>
  
  <p>So I'm looking for input from the community: for those of you who have grown past the point of 1 or 2 staff to handle inbound email, what do you do to capture the email and respond to it?</p>
  
  <p>Thank you</p>
  
  <p>EDIT:
  I looked at CiviRules, but unfortunately it lacks some conditions and some actions to make this possible:</p>
  
  <ul>
  <li>I could say "Take an action when an activity of type Inbound Email is received"</li>
  <li>But I could not say that the action should be to create a case.  </li>
  <li>Presumably I also could not say to assign the activity to the case.</li>
  <li>I also could not say "Only take this action if the activity is not already associated with a case" (e.g. if the email subject has a case ID)</li>
  </ul>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-03-20T12:53:12.340Z
Comments.Text: One of the orgs I know does use a type of tagging system to know who is handling, but they also have a designated daily person who is the default handler for that day so that everything gets handled. But to-date all the installations I've worked with have always involved at least some custom code to integrate with how the org works.
Comments.UserDisplayName: Demerit
Tags: <email><civicase>
Title: What are some best practices for inbound email handling with CiviCRM?
ThreadText: # What are some best practices for inbound email handling with CiviCRM?
  
  (Asked by: username_0 on 2018-03-18)
  
  Our organization has grown past the point where one person can handle the inbound e-mail from our members. I'm looking for best practices from the community on how to handle this.
  
  We don't want to give all of our staff access directly to the e-mail account. As staff come and go, we would have to connstantly change the password to that account. Also, giving everyone direct access to the account would require a tagging system to know who is handling what message. This seems less than ideal.
  
  We could adopt a ticketing system, either something like osTicket or something like Zendesk. But I think it would be nice to have all of our interactions with our members in one clear place. After all, isn't that what a CRM is supposed to do for you?
  
  I looked at CiviCase and at first glance it appears to be exactly right. But for some reason [out of the box CiviCRM does not create a new case for each new inbound e-mail](https://civicrm.stackexchange.com/questions/24164/how-do-i-automatically-create-a-case-on-inbound-email). Discovering this got me thinking that perhaps opening a case for each inbound e-mail is not the right approach?
  
  So I'm looking for input from the community: for those of you who have grown past the point of 1 or 2 staff to handle inbound email, what do you do to capture the email and respond to it?
  
  Thank you
  
  EDIT:
  I looked at CiviRules, but unfortunately it lacks some conditions and some actions to make this possible:
  
  * I could say "Take an action when an activity of type Inbound Email is received"
  * But I could not say that the action should be to create a case.
  * Presumably I also could not say to assign the activity to the case.
  * I also could not say "Only take this action if the activity is not already associated with a case" (e.g. if the email subject has a case ID)
  
  **Tags:** email, civicase
  
  > **Comments:**
  > **username_1**: One of the orgs I know does use a type of tagging system to know who is handling, but they also have a designated daily person who is the default handler for that day so that everything gets handled. But to-date all the installations I've worked with have always involved at least some custom code to integrate with how the org works.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-03-19. Score: 1
  
  Another option to explore is if CiviRules has a 'create case' capability that could be triggered from creating an Activity, which itself had been created by inbound email
  
  > **Comments:**
  > **username_0**: Unfortunately CiviRules lacked the necessary conditions and triggers.  I added some details in an edit to my original question.  
  > **username_2**: Then I would think the solution is an extension that would eg work on basis that an email to email address X should trigger a new case, assign to default Coordinator etc if no #caseid is in the subject. doesn't sound like a big job  
  > **username_2**: also did you read this? https://civicrm.org/blog/dahndy/leveraging-civicrm-email-to-activity-processing-in-gmail in case it adds any new thoughts  
  > **username_2**: fyi we did some improvements to Inbound Email so #caseid works in case that gives you some ideas: https://civicrm.org/blog/petednz/improvements-to-inbound-emails-to-cases-in-4730  
  > **username_2**: oh. sorry that was to core not via an extension  
  
  ---
  
  