# Requesting Help/Insight Identifying Work-Around(s) for Modifying Cases Using Group\[ed\] Users

**URL:** <https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290>\
**Category:** Users\
**Created:** [January 24, 2013, 3:12pm UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290 "2013-01-24T15:12:21Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nadi\_Kaonga](https://dimagi.b-cdn.net/letter_avatar_proxy/v4/letter/n/65b543/32.png) [@Nadi\_Kaonga](https://forum.dimagi.com/u/Nadi_Kaonga)\
**Post date:** [January 24, 2013, 3:12pm UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290/1 "2013-01-24T15:12:21Z")

</div>

Dear Fellow CommCare Users and Implementers,  
We hope this finds you doing well. We are writing to request your thoughts  
and insights on group[ed] users in CommCareHQ. [Apologies in advance for  
the lengthy post, but wanted to provide as much detail as possible.]

We are working on a project in Ethiopia that requires regional users for a  
catchment area and individual users within that catchment area. The set-up  
is such that the individual users, who are Health Extension Workers (HEWs),  
are mobile users, and for each mobile user, a case has been set up. The  
case represents the individual (HEW) and includes key data points like  
their name, location, mobile phone number (if available) and health center  
that they work in. The regional users are office-based data entry personnel  
who have access to the same forms but use CloudCare and to submit the form  
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to each  
of the mobile workers and the corresponding "case". The regional user then  
selects a case in CloudCare and is able to open the form under that case  
and enter the data and submit.

Therefore, we have the regional user linked to each of the individual users  
for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an HEW  
relocates to another health post in the same region) as a regional user has  
posed problems. Since the regional user has been grouped, an error message  
pops up to notify us that grouped users can not submit such modifying  
information.

To address this problem--at least for registering new HEWs (or cases), we  
thought we could set up a new user that was not grouped. This ungrouped  
user could then register a new HEW (or case) in CloudCare, then work could  
be done to properly group the HEW into the appropriate region and create a  
mobile user to link to that new case after the initial registration. This  
has worked fine.

Where we have been having issues is to modify an existing case. Since the  
ungrouped user is 'new', it does not have all of the HEW data (or cases)  
that the regional users have -- therefore, there is no way to select the  
appropriate HEW (or case) to modify. And if we try and modify HEW data (or  
a case), we receive an error message notifying us that group[ed] users can  
not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight  
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please do  
not hesitate to let us know.

With much appreciation,  
Nadi Nina Kaonga (on behalf of colleagues)

---

<div class="post-metadata">

**Author:** ![Ray\_B](https://dimagi.b-cdn.net/user_avatar/forum.dimagi.com/ray_b/32/618_2.png) [@Ray\_B](https://forum.dimagi.com/u/Ray_B)\
**Post date:** [January 25, 2013, 1:50pm UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290/2 "2013-01-25T13:50:39Z")

</div>

While I'm not sure if this will help (or simply cause confusion), the image  
below illustrates the design we have settled on for a similar scenario.

I think the key difference between your design and this one is that we  
decided model each community as a CommCare case, rather than each CHW. We  
create one sharing group for each community and put the CHW and health post  
nurse into this group. The design allows us to put as many users as  
desired into each sharing group --- essentially changing the list of people  
providing care to any community. Each community case is owned by the  
sharing group created for that community and each sub-case of the community  
has been setup to inherit the owner of the community case.  
[_note_: the auto-inheritance of ownership require custom-coded xform code;  
the Wiki [1] includes some documentation to handle situations where a user  
belongs to more than one sharing group]

This seems to make it easier to handle situations where CHWs are assigned  
to more/less/different communities, although other scenarios could become  
more challenging to address.

Cheers, Ray

1 -  
[https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups](https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups)

[image: Inline image 1]

 ![](https://dimagi.b-cdn.net/uploads/default/original/1X/100b9c74de82929ada11cf0f0f8f48b07069d409.png)

> **···**
>
> On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga wrote:
> 
> > Dear Fellow CommCare Users and Implementers,  
> > We hope this finds you doing well. We are writing to request your  
> > thoughts and insights on group[ed] users in CommCareHQ. [Apologies in  
> > advance for the lengthy post, but wanted to provide as much detail as  
> > possible.]
> > 
> > We are working on a project in Ethiopia that requires regional users for a  
> > catchment area and individual users within that catchment area. The set-up  
> > is such that the individual users, who are Health Extension Workers (HEWs),  
> > are mobile users, and for each mobile user, a case has been set up. The  
> > case represents the individual (HEW) and includes key data points like  
> > their name, location, mobile phone number (if available) and health center  
> > that they work in. The regional users are office-based data entry personnel  
> > who have access to the same forms but use CloudCare and to submit the form  
> > on behalf of the HEW.
> > 
> > To submit forms on behalf of the HEW, the regional user is linked to each  
> > of the mobile workers and the corresponding "case". The regional user then  
> > selects a case in CloudCare and is able to open the form under that case  
> > and enter the data and submit.
> > 
> > Therefore, we have the regional user linked to each of the individual  
> > users for that region. Hence, group[ed] users.
> > 
> > However, we have found that registering and modifying a case (i.e., an HEW  
> > relocates to another health post in the same region) as a regional user has  
> > posed problems. Since the regional user has been grouped, an error message  
> > pops up to notify us that grouped users can not submit such modifying  
> > information.
> > 
> > To address this problem--at least for registering new HEWs (or cases), we  
> > thought we could set up a new user that was not grouped. This ungrouped  
> > user could then register a new HEW (or case) in CloudCare, then work could  
> > be done to properly group the HEW into the appropriate region and create a  
> > mobile user to link to that new case after the initial registration. This  
> > has worked fine.
> > 
> > Where we have been having issues is to modify an existing case. Since the  
> > ungrouped user is 'new', it does not have all of the HEW data (or cases)  
> > that the regional users have -- therefore, there is no way to select the  
> > appropriate HEW (or case) to modify. And if we try and modify HEW data (or  
> > a case), we receive an error message notifying us that group[ed] users can  
> > not make such changes in the CommCare system at this time.
> > 
> > Have any of you run into a similar issue? Do any of you have insight  
> > and/or suggestions on this issue? Please advise.
> > 
> > Thank you and if you require more information or clarification, please do  
> > not hesitate to let us know.
> > 
> > With much appreciation,  
> > Nadi Nina Kaonga (on behalf of colleagues)
> 
> --  
> Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)

---

<div class="post-metadata">

**Author:** ![czue](https://dimagi.b-cdn.net/user_avatar/forum.dimagi.com/czue/32/493_2.png) [@czue](https://forum.dimagi.com/u/czue)\
**Post date:** [January 28, 2013, 11:54pm UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290/3 "2013-01-28T23:54:01Z")

</div>

Hi Nadi,

I'm having a hard time totally understanding the exact use case/problem  
you're describing, but I think it's possible that it boils down to  
something quite simple:

How can I assign a case (HEW) from one group (region) to another in  
CommCare HQ?

I know you've been using cloudcare for most of your workflows, but possibly  
the reassign cases tool[1] will be able to do this for you?

Apologies if I've vastly misunderstood what you need to do and gotten this  
all wrong, and please feel free to clarify.

thanks,  
Cory

[1] [Log In - Dimagi Confluence](https://wiki.commcarehq.org/display/cctroubleshoot/914.++Reassign+Cases)

 ![](https://dimagi.b-cdn.net/uploads/default/original/1X/100b9c74de82929ada11cf0f0f8f48b07069d409.png)

> **···**
>
> On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting wrote:
> 
> > While I'm not sure if this will help (or simply cause confusion), the  
> > image below illustrates the design we have settled on for a similar  
> > scenario.
> > 
> > I think the key difference between your design and this one is that we  
> > decided model each community as a CommCare case, rather than each CHW. We  
> > create one sharing group for each community and put the CHW and health post  
> > nurse into this group. The design allows us to put as many users as  
> > desired into each sharing group --- essentially changing the list of people  
> > providing care to any community. Each community case is owned by the  
> > sharing group created for that community and each sub-case of the community  
> > has been setup to inherit the owner of the community case.  
> > [_note_: the auto-inheritance of ownership require custom-coded xform  
> > code; the Wiki [1] includes some documentation to handle situations where a  
> > user belongs to more than one sharing group]
> > 
> > This seems to make it easier to handle situations where CHWs are assigned  
> > to more/less/different communities, although other scenarios could become  
> > more challenging to address.
> > 
> > Cheers, Ray
> > 
> > 1 -  
> > [https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups](https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups)
> > 
> > [image: Inline image 1]
> > 
> > On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga [nkaonga@gmail.com](mailto:nkaonga@gmail.com) wrote:
> > 
> > > Dear Fellow CommCare Users and Implementers,  
> > > We hope this finds you doing well. We are writing to request your  
> > > thoughts and insights on group[ed] users in CommCareHQ. [Apologies in  
> > > advance for the lengthy post, but wanted to provide as much detail as  
> > > possible.]
> > > 
> > > We are working on a project in Ethiopia that requires regional users for  
> > > a catchment area and individual users within that catchment area. The  
> > > set-up is such that the individual users, who are Health Extension Workers  
> > > (HEWs), are mobile users, and for each mobile user, a case has been set up.  
> > > The case represents the individual (HEW) and includes key data points like  
> > > their name, location, mobile phone number (if available) and health center  
> > > that they work in. The regional users are office-based data entry personnel  
> > > who have access to the same forms but use CloudCare and to submit the form  
> > > on behalf of the HEW.
> > > 
> > > To submit forms on behalf of the HEW, the regional user is linked to each  
> > > of the mobile workers and the corresponding "case". The regional user then  
> > > selects a case in CloudCare and is able to open the form under that case  
> > > and enter the data and submit.
> > > 
> > > Therefore, we have the regional user linked to each of the individual  
> > > users for that region. Hence, group[ed] users.
> > > 
> > > However, we have found that registering and modifying a case (i.e., an  
> > > HEW relocates to another health post in the same region) as a regional user  
> > > has posed problems. Since the regional user has been grouped, an error  
> > > message pops up to notify us that grouped users can not submit such  
> > > modifying information.
> > > 
> > > To address this problem--at least for registering new HEWs (or cases), we  
> > > thought we could set up a new user that was not grouped. This ungrouped  
> > > user could then register a new HEW (or case) in CloudCare, then work could  
> > > be done to properly group the HEW into the appropriate region and create a  
> > > mobile user to link to that new case after the initial registration. This  
> > > has worked fine.
> > > 
> > > Where we have been having issues is to modify an existing case. Since  
> > > the ungrouped user is 'new', it does not have all of the HEW data (or  
> > > cases) that the regional users have -- therefore, there is no way to select  
> > > the appropriate HEW (or case) to modify. And if we try and modify HEW data  
> > > (or a case), we receive an error message notifying us that group[ed] users  
> > > can not make such changes in the CommCare system at this time.
> > > 
> > > Have any of you run into a similar issue? Do any of you have insight  
> > > and/or suggestions on this issue? Please advise.
> > > 
> > > Thank you and if you require more information or clarification, please do  
> > > not hesitate to let us know.
> > > 
> > > With much appreciation,  
> > > Nadi Nina Kaonga (on behalf of colleagues)
> > 
> > --  
> > Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)

---

<div class="post-metadata">

**Author:** ![Nadi\_Kaonga](https://dimagi.b-cdn.net/letter_avatar_proxy/v4/letter/n/65b543/32.png) [@Nadi\_Kaonga](https://forum.dimagi.com/u/Nadi_Kaonga)\
**Post date:** [January 29, 2013, 2:02am UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290/4 "2013-01-29T02:02:00Z")

</div>

Dear Ray,  
Thank you very much for the feedback and the information. With your custom  
case-sharing setting, have you been able to easily modify cases?

Dear Cory,  
That is not exactly the problem, but may work towards the solution. My  
only concern is if we re-assign cases to another user (from the region  
user) and then modify the case, would that alter any of the form  
submissions that that case has made? Please advise.

Thank you both and we are looking forward to hearing back from you.

All the best,

 ![](https://dimagi.b-cdn.net/uploads/default/original/1X/100b9c74de82929ada11cf0f0f8f48b07069d409.png)

> **···**
>
> -- Nadi Nina Kaonga
> 
> On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue [czue@dimagi.com](mailto:czue@dimagi.com) wrote:
> 
> > Hi Nadi,
> > 
> > I'm having a hard time totally understanding the exact use case/problem  
> > you're describing, but I think it's possible that it boils down to  
> > something quite simple:
> > 
> > How can I assign a case (HEW) from one group (region) to another in  
> > CommCare HQ?
> > 
> > I know you've been using cloudcare for most of your workflows, but  
> > possibly the reassign cases tool[1] will be able to do this for you?
> > 
> > Apologies if I've vastly misunderstood what you need to do and gotten this  
> > all wrong, and please feel free to clarify.
> > 
> > thanks,  
> > Cory
> > 
> > [1]  
> > [Log In - Dimagi Confluence](https://wiki.commcarehq.org/display/cctroubleshoot/914.++Reassign+Cases)
> > 
> > On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting [ray@tula.org](mailto:ray@tula.org) wrote:
> > 
> > > While I'm not sure if this will help (or simply cause confusion), the  
> > > image below illustrates the design we have settled on for a similar  
> > > scenario.
> > > 
> > > I think the key difference between your design and this one is that we  
> > > decided model each community as a CommCare case, rather than each CHW. We  
> > > create one sharing group for each community and put the CHW and health post  
> > > nurse into this group. The design allows us to put as many users as  
> > > desired into each sharing group --- essentially changing the list of people  
> > > providing care to any community. Each community case is owned by the  
> > > sharing group created for that community and each sub-case of the community  
> > > has been setup to inherit the owner of the community case.  
> > > [_note_: the auto-inheritance of ownership require custom-coded xform  
> > > code; the Wiki [1] includes some documentation to handle situations where a  
> > > user belongs to more than one sharing group]
> > > 
> > > This seems to make it easier to handle situations where CHWs are assigned  
> > > to more/less/different communities, although other scenarios could become  
> > > more challenging to address.
> > > 
> > > Cheers, Ray
> > > 
> > > 1 -  
> > > [https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups](https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups)
> > > 
> > > [image: Inline image 1]
> > > 
> > > On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga [nkaonga@gmail.com](mailto:nkaonga@gmail.com) wrote:
> > > 
> > > > Dear Fellow CommCare Users and Implementers,  
> > > > We hope this finds you doing well. We are writing to request your  
> > > > thoughts and insights on group[ed] users in CommCareHQ. [Apologies in  
> > > > advance for the lengthy post, but wanted to provide as much detail as  
> > > > possible.]
> > > > 
> > > > We are working on a project in Ethiopia that requires regional users for  
> > > > a catchment area and individual users within that catchment area. The  
> > > > set-up is such that the individual users, who are Health Extension Workers  
> > > > (HEWs), are mobile users, and for each mobile user, a case has been set up.  
> > > > The case represents the individual (HEW) and includes key data points like  
> > > > their name, location, mobile phone number (if available) and health center  
> > > > that they work in. The regional users are office-based data entry personnel  
> > > > who have access to the same forms but use CloudCare and to submit the form  
> > > > on behalf of the HEW.
> > > > 
> > > > To submit forms on behalf of the HEW, the regional user is linked to  
> > > > each of the mobile workers and the corresponding "case". The regional user  
> > > > then selects a case in CloudCare and is able to open the form under that  
> > > > case and enter the data and submit.
> > > > 
> > > > Therefore, we have the regional user linked to each of the individual  
> > > > users for that region. Hence, group[ed] users.
> > > > 
> > > > However, we have found that registering and modifying a case (i.e., an  
> > > > HEW relocates to another health post in the same region) as a regional user  
> > > > has posed problems. Since the regional user has been grouped, an error  
> > > > message pops up to notify us that grouped users can not submit such  
> > > > modifying information.
> > > > 
> > > > To address this problem--at least for registering new HEWs (or cases),  
> > > > we thought we could set up a new user that was not grouped. This ungrouped  
> > > > user could then register a new HEW (or case) in CloudCare, then work could  
> > > > be done to properly group the HEW into the appropriate region and create a  
> > > > mobile user to link to that new case after the initial registration. This  
> > > > has worked fine.
> > > > 
> > > > Where we have been having issues is to modify an existing case. Since  
> > > > the ungrouped user is 'new', it does not have all of the HEW data (or  
> > > > cases) that the regional users have -- therefore, there is no way to select  
> > > > the appropriate HEW (or case) to modify. And if we try and modify HEW data  
> > > > (or a case), we receive an error message notifying us that group[ed] users  
> > > > can not make such changes in the CommCare system at this time.
> > > > 
> > > > Have any of you run into a similar issue? Do any of you have insight  
> > > > and/or suggestions on this issue? Please advise.
> > > > 
> > > > Thank you and if you require more information or clarification, please  
> > > > do not hesitate to let us know.
> > > > 
> > > > With much appreciation,  
> > > > Nadi Nina Kaonga (on behalf of colleagues)
> > > 
> > > --  
> > > Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)
> > 
> > --  
> > You received this message because you are subscribed to the Google Groups  
> > "commcare-users" group.  
> > To unsubscribe from this group, send email to  
> > [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).  
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![czue](https://dimagi.b-cdn.net/user_avatar/forum.dimagi.com/czue/32/493_2.png) [@czue](https://forum.dimagi.com/u/czue)\
**Post date:** [January 29, 2013, 2:14am UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290/5 "2013-01-29T02:14:57Z")

</div>

> That is not exactly the problem, but may work towards the solution. My  
> only concern is if we re-assign cases to another user (from the region  
> user) and then modify the case, would that alter any of the form  
> submissions that that case has made? Please advise.

It shouldn't touch any of the previous form submissions. It will be like a  
new submission was made that just updates the case ownership.

Cory

 ![](https://dimagi.b-cdn.net/uploads/default/original/1X/100b9c74de82929ada11cf0f0f8f48b07069d409.png)

> **···**
>
> On Mon, Jan 28, 2013 at 9:02 PM, Nadi Kaonga wrote:
> 
> > Thank you both and we are looking forward to hearing back from you.
> > 
> > All the best,
> > 
> > --  
> > Nadi Nina Kaonga
> > 
> > On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue [czue@dimagi.com](mailto:czue@dimagi.com) wrote:
> > 
> > > Hi Nadi,
> > > 
> > > I'm having a hard time totally understanding the exact use case/problem  
> > > you're describing, but I think it's possible that it boils down to  
> > > something quite simple:
> > > 
> > > How can I assign a case (HEW) from one group (region) to another in  
> > > CommCare HQ?
> > > 
> > > I know you've been using cloudcare for most of your workflows, but  
> > > possibly the reassign cases tool[1] will be able to do this for you?
> > > 
> > > Apologies if I've vastly misunderstood what you need to do and gotten  
> > > this all wrong, and please feel free to clarify.
> > > 
> > > thanks,  
> > > Cory
> > > 
> > > [1]  
> > > [Log In - Dimagi Confluence](https://wiki.commcarehq.org/display/cctroubleshoot/914.++Reassign+Cases)
> > > 
> > > On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting [ray@tula.org](mailto:ray@tula.org) wrote:
> > > 
> > > > While I'm not sure if this will help (or simply cause confusion), the  
> > > > image below illustrates the design we have settled on for a similar  
> > > > scenario.
> > > > 
> > > > I think the key difference between your design and this one is that we  
> > > > decided model each community as a CommCare case, rather than each CHW. We  
> > > > create one sharing group for each community and put the CHW and health post  
> > > > nurse into this group. The design allows us to put as many users as  
> > > > desired into each sharing group --- essentially changing the list of people  
> > > > providing care to any community. Each community case is owned by the  
> > > > sharing group created for that community and each sub-case of the community  
> > > > has been setup to inherit the owner of the community case.  
> > > > [_note_: the auto-inheritance of ownership require custom-coded xform  
> > > > code; the Wiki [1] includes some documentation to handle situations where a  
> > > > user belongs to more than one sharing group]
> > > > 
> > > > This seems to make it easier to handle situations where CHWs are  
> > > > assigned to more/less/different communities, although other scenarios could  
> > > > become more challenging to address.
> > > > 
> > > > Cheers, Ray
> > > > 
> > > > 1 -  
> > > > [https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups](https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups)
> > > > 
> > > > [image: Inline image 1]
> > > > 
> > > > On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga [nkaonga@gmail.com](mailto:nkaonga@gmail.com) wrote:
> > > > 
> > > > > Dear Fellow CommCare Users and Implementers,  
> > > > > We hope this finds you doing well. We are writing to request your  
> > > > > thoughts and insights on group[ed] users in CommCareHQ. [Apologies in  
> > > > > advance for the lengthy post, but wanted to provide as much detail as  
> > > > > possible.]
> > > > > 
> > > > > We are working on a project in Ethiopia that requires regional users  
> > > > > for a catchment area and individual users within that catchment area. The  
> > > > > set-up is such that the individual users, who are Health Extension Workers  
> > > > > (HEWs), are mobile users, and for each mobile user, a case has been set up.  
> > > > > The case represents the individual (HEW) and includes key data points like  
> > > > > their name, location, mobile phone number (if available) and health center  
> > > > > that they work in. The regional users are office-based data entry personnel  
> > > > > who have access to the same forms but use CloudCare and to submit the form  
> > > > > on behalf of the HEW.
> > > > > 
> > > > > To submit forms on behalf of the HEW, the regional user is linked to  
> > > > > each of the mobile workers and the corresponding "case". The regional user  
> > > > > then selects a case in CloudCare and is able to open the form under that  
> > > > > case and enter the data and submit.
> > > > > 
> > > > > Therefore, we have the regional user linked to each of the individual  
> > > > > users for that region. Hence, group[ed] users.
> > > > > 
> > > > > However, we have found that registering and modifying a case (i.e., an  
> > > > > HEW relocates to another health post in the same region) as a regional user  
> > > > > has posed problems. Since the regional user has been grouped, an error  
> > > > > message pops up to notify us that grouped users can not submit such  
> > > > > modifying information.
> > > > > 
> > > > > To address this problem--at least for registering new HEWs (or cases),  
> > > > > we thought we could set up a new user that was not grouped. This ungrouped  
> > > > > user could then register a new HEW (or case) in CloudCare, then work could  
> > > > > be done to properly group the HEW into the appropriate region and create a  
> > > > > mobile user to link to that new case after the initial registration. This  
> > > > > has worked fine.
> > > > > 
> > > > > Where we have been having issues is to modify an existing case. Since  
> > > > > the ungrouped user is 'new', it does not have all of the HEW data (or  
> > > > > cases) that the regional users have -- therefore, there is no way to select  
> > > > > the appropriate HEW (or case) to modify. And if we try and modify HEW data  
> > > > > (or a case), we receive an error message notifying us that group[ed] users  
> > > > > can not make such changes in the CommCare system at this time.
> > > > > 
> > > > > Have any of you run into a similar issue? Do any of you have insight  
> > > > > and/or suggestions on this issue? Please advise.
> > > > > 
> > > > > Thank you and if you require more information or clarification, please  
> > > > > do not hesitate to let us know.
> > > > > 
> > > > > With much appreciation,  
> > > > > Nadi Nina Kaonga (on behalf of colleagues)
> > > > 
> > > > --  
> > > > Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)
> > > 
> > > --  
> > > You received this message because you are subscribed to the Google Groups  
> > > "commcare-users" group.  
> > > To unsubscribe from this group, send email to  
> > > [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).  
> > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > 
> > --  
> > You received this message because you are subscribed to the Google Groups  
> > "commcare-users" group.  
> > To unsubscribe from this group and stop receiving emails from it, send an  
> > email to [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).  
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![Ray\_B](https://dimagi.b-cdn.net/user_avatar/forum.dimagi.com/ray_b/32/618_2.png) [@Ray\_B](https://forum.dimagi.com/u/Ray_B)\
**Post date:** [January 29, 2013, 1:20pm UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290/6 "2013-01-29T13:20:47Z")

</div>

Re: "_With your custom case-sharing setting, have you been able to easily  
modify cases?_"  
While it has been working fine in testing, we don't yet have any field  
experience with case-sharing. I'd be interested to hear how your final  
design works out.

Best regards, Ray

 ![](https://dimagi.b-cdn.net/uploads/default/original/1X/100b9c74de82929ada11cf0f0f8f48b07069d409.png)

> **···**
>
> On Mon, Jan 28, 2013 at 9:02 PM, Nadi Kaonga wrote:
> 
> > Dear Ray,  
> > Thank you very much for the feedback and the information. With your  
> > custom case-sharing setting, have you been able to easily modify cases?
> > 
> > Dear Cory,  
> > That is not exactly the problem, but may work towards the solution. My  
> > only concern is if we re-assign cases to another user (from the region  
> > user) and then modify the case, would that alter any of the form  
> > submissions that that case has made? Please advise.
> > 
> > Thank you both and we are looking forward to hearing back from you.
> > 
> > All the best,
> > 
> > --  
> > Nadi Nina Kaonga
> > 
> > On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue [czue@dimagi.com](mailto:czue@dimagi.com) wrote:
> > 
> > > Hi Nadi,
> > > 
> > > I'm having a hard time totally understanding the exact use case/problem  
> > > you're describing, but I think it's possible that it boils down to  
> > > something quite simple:
> > > 
> > > How can I assign a case (HEW) from one group (region) to another in  
> > > CommCare HQ?
> > > 
> > > I know you've been using cloudcare for most of your workflows, but  
> > > possibly the reassign cases tool[1] will be able to do this for you?
> > > 
> > > Apologies if I've vastly misunderstood what you need to do and gotten  
> > > this all wrong, and please feel free to clarify.
> > > 
> > > thanks,  
> > > Cory
> > > 
> > > [1]  
> > > [Log In - Dimagi Confluence](https://wiki.commcarehq.org/display/cctroubleshoot/914.++Reassign+Cases)
> > > 
> > > On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting [ray@tula.org](mailto:ray@tula.org) wrote:
> > > 
> > > > While I'm not sure if this will help (or simply cause confusion), the  
> > > > image below illustrates the design we have settled on for a similar  
> > > > scenario.
> > > > 
> > > > I think the key difference between your design and this one is that we  
> > > > decided model each community as a CommCare case, rather than each CHW. We  
> > > > create one sharing group for each community and put the CHW and health post  
> > > > nurse into this group. The design allows us to put as many users as  
> > > > desired into each sharing group --- essentially changing the list of people  
> > > > providing care to any community. Each community case is owned by the  
> > > > sharing group created for that community and each sub-case of the community  
> > > > has been setup to inherit the owner of the community case.  
> > > > [_note_: the auto-inheritance of ownership require custom-coded xform  
> > > > code; the Wiki [1] includes some documentation to handle situations where a  
> > > > user belongs to more than one sharing group]
> > > > 
> > > > This seems to make it easier to handle situations where CHWs are  
> > > > assigned to more/less/different communities, although other scenarios could  
> > > > become more challenging to address.
> > > > 
> > > > Cheers, Ray
> > > > 
> > > > 1 -  
> > > > [https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups](https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups)
> > > > 
> > > > [image: Inline image 1]
> > > > 
> > > > On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga [nkaonga@gmail.com](mailto:nkaonga@gmail.com) wrote:
> > > > 
> > > > > Dear Fellow CommCare Users and Implementers,  
> > > > > We hope this finds you doing well. We are writing to request your  
> > > > > thoughts and insights on group[ed] users in CommCareHQ. [Apologies in  
> > > > > advance for the lengthy post, but wanted to provide as much detail as  
> > > > > possible.]
> > > > > 
> > > > > We are working on a project in Ethiopia that requires regional users  
> > > > > for a catchment area and individual users within that catchment area. The  
> > > > > set-up is such that the individual users, who are Health Extension Workers  
> > > > > (HEWs), are mobile users, and for each mobile user, a case has been set up.  
> > > > > The case represents the individual (HEW) and includes key data points like  
> > > > > their name, location, mobile phone number (if available) and health center  
> > > > > that they work in. The regional users are office-based data entry personnel  
> > > > > who have access to the same forms but use CloudCare and to submit the form  
> > > > > on behalf of the HEW.
> > > > > 
> > > > > To submit forms on behalf of the HEW, the regional user is linked to  
> > > > > each of the mobile workers and the corresponding "case". The regional user  
> > > > > then selects a case in CloudCare and is able to open the form under that  
> > > > > case and enter the data and submit.
> > > > > 
> > > > > Therefore, we have the regional user linked to each of the individual  
> > > > > users for that region. Hence, group[ed] users.
> > > > > 
> > > > > However, we have found that registering and modifying a case (i.e., an  
> > > > > HEW relocates to another health post in the same region) as a regional user  
> > > > > has posed problems. Since the regional user has been grouped, an error  
> > > > > message pops up to notify us that grouped users can not submit such  
> > > > > modifying information.
> > > > > 
> > > > > To address this problem--at least for registering new HEWs (or cases),  
> > > > > we thought we could set up a new user that was not grouped. This ungrouped  
> > > > > user could then register a new HEW (or case) in CloudCare, then work could  
> > > > > be done to properly group the HEW into the appropriate region and create a  
> > > > > mobile user to link to that new case after the initial registration. This  
> > > > > has worked fine.
> > > > > 
> > > > > Where we have been having issues is to modify an existing case. Since  
> > > > > the ungrouped user is 'new', it does not have all of the HEW data (or  
> > > > > cases) that the regional users have -- therefore, there is no way to select  
> > > > > the appropriate HEW (or case) to modify. And if we try and modify HEW data  
> > > > > (or a case), we receive an error message notifying us that group[ed] users  
> > > > > can not make such changes in the CommCare system at this time.
> > > > > 
> > > > > Have any of you run into a similar issue? Do any of you have insight  
> > > > > and/or suggestions on this issue? Please advise.
> > > > > 
> > > > > Thank you and if you require more information or clarification, please  
> > > > > do not hesitate to let us know.
> > > > > 
> > > > > With much appreciation,  
> > > > > Nadi Nina Kaonga (on behalf of colleagues)
> > > > 
> > > > --  
> > > > Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)
> > > 
> > > --  
> > > You received this message because you are subscribed to the Google Groups  
> > > "commcare-users" group.  
> > > To unsubscribe from this group, send email to  
> > > [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).  
> > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > 
> > --  
> > You received this message because you are subscribed to the Google Groups  
> > "commcare-users" group.  
> > To unsubscribe from this group and stop receiving emails from it, send an  
> > email to [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).
> > 
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> 
> --  
> Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)

---

<div class="post-metadata">

**Author:** ![Nadi\_Kaonga](https://dimagi.b-cdn.net/letter_avatar_proxy/v4/letter/n/65b543/32.png) [@Nadi\_Kaonga](https://forum.dimagi.com/u/Nadi_Kaonga)\
**Post date:** [January 29, 2013, 2:22am UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290/7 "2013-01-29T02:22:52Z")

</div>

Thank you!

 ![](https://dimagi.b-cdn.net/uploads/default/original/1X/100b9c74de82929ada11cf0f0f8f48b07069d409.png)

> **···**
>
> -- Nadi Nina Kaonga
> 
> On Mon, Jan 28, 2013 at 9:14 PM, Cory Zue [czue@dimagi.com](mailto:czue@dimagi.com) wrote:
> 
> > On Mon, Jan 28, 2013 at 9:02 PM, Nadi Kaonga [nkaonga@gmail.com](mailto:nkaonga@gmail.com) wrote:
> > 
> > > That is not exactly the problem, but may work towards the solution. My  
> > > only concern is if we re-assign cases to another user (from the region  
> > > user) and then modify the case, would that alter any of the form  
> > > submissions that that case has made? Please advise.
> > 
> > It shouldn't touch any of the previous form submissions. It will be like a  
> > new submission was made that just updates the case ownership.
> > 
> > Cory
> > 
> > > Thank you both and we are looking forward to hearing back from you.
> > > 
> > > All the best,
> > > 
> > > --  
> > > Nadi Nina Kaonga
> > > 
> > > On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue [czue@dimagi.com](mailto:czue@dimagi.com) wrote:
> > > 
> > > > Hi Nadi,
> > > > 
> > > > I'm having a hard time totally understanding the exact use case/problem  
> > > > you're describing, but I think it's possible that it boils down to  
> > > > something quite simple:
> > > > 
> > > > How can I assign a case (HEW) from one group (region) to another in  
> > > > CommCare HQ?
> > > > 
> > > > I know you've been using cloudcare for most of your workflows, but  
> > > > possibly the reassign cases tool[1] will be able to do this for you?
> > > > 
> > > > Apologies if I've vastly misunderstood what you need to do and gotten  
> > > > this all wrong, and please feel free to clarify.
> > > > 
> > > > thanks,  
> > > > Cory
> > > > 
> > > > [1]  
> > > > [Log In - Dimagi Confluence](https://wiki.commcarehq.org/display/cctroubleshoot/914.++Reassign+Cases)
> > > > 
> > > > On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting [ray@tula.org](mailto:ray@tula.org) wrote:
> > > > 
> > > > > While I'm not sure if this will help (or simply cause confusion), the  
> > > > > image below illustrates the design we have settled on for a similar  
> > > > > scenario.
> > > > > 
> > > > > I think the key difference between your design and this one is that we  
> > > > > decided model each community as a CommCare case, rather than each CHW. We  
> > > > > create one sharing group for each community and put the CHW and health post  
> > > > > nurse into this group. The design allows us to put as many users as  
> > > > > desired into each sharing group --- essentially changing the list of people  
> > > > > providing care to any community. Each community case is owned by the  
> > > > > sharing group created for that community and each sub-case of the community  
> > > > > has been setup to inherit the owner of the community case.  
> > > > > [_note_: the auto-inheritance of ownership require custom-coded xform  
> > > > > code; the Wiki [1] includes some documentation to handle situations where a  
> > > > > user belongs to more than one sharing group]
> > > > > 
> > > > > This seems to make it easier to handle situations where CHWs are  
> > > > > assigned to more/less/different communities, although other scenarios could  
> > > > > become more challenging to address.
> > > > > 
> > > > > Cheers, Ray
> > > > > 
> > > > > 1 -  
> > > > > [https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups](https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups)
> > > > > 
> > > > > [image: Inline image 1]
> > > > > 
> > > > > On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga [nkaonga@gmail.com](mailto:nkaonga@gmail.com)wrote:
> > > > > 
> > > > > > Dear Fellow CommCare Users and Implementers,  
> > > > > > We hope this finds you doing well. We are writing to request your  
> > > > > > thoughts and insights on group[ed] users in CommCareHQ. [Apologies in  
> > > > > > advance for the lengthy post, but wanted to provide as much detail as  
> > > > > > possible.]
> > > > > > 
> > > > > > We are working on a project in Ethiopia that requires regional users  
> > > > > > for a catchment area and individual users within that catchment area. The  
> > > > > > set-up is such that the individual users, who are Health Extension Workers  
> > > > > > (HEWs), are mobile users, and for each mobile user, a case has been set up.  
> > > > > > The case represents the individual (HEW) and includes key data points like  
> > > > > > their name, location, mobile phone number (if available) and health center  
> > > > > > that they work in. The regional users are office-based data entry personnel  
> > > > > > who have access to the same forms but use CloudCare and to submit the form  
> > > > > > on behalf of the HEW.
> > > > > > 
> > > > > > To submit forms on behalf of the HEW, the regional user is linked to  
> > > > > > each of the mobile workers and the corresponding "case". The regional user  
> > > > > > then selects a case in CloudCare and is able to open the form under that  
> > > > > > case and enter the data and submit.
> > > > > > 
> > > > > > Therefore, we have the regional user linked to each of the individual  
> > > > > > users for that region. Hence, group[ed] users.
> > > > > > 
> > > > > > However, we have found that registering and modifying a case (i.e., an  
> > > > > > HEW relocates to another health post in the same region) as a regional user  
> > > > > > has posed problems. Since the regional user has been grouped, an error  
> > > > > > message pops up to notify us that grouped users can not submit such  
> > > > > > modifying information.
> > > > > > 
> > > > > > To address this problem--at least for registering new HEWs (or cases),  
> > > > > > we thought we could set up a new user that was not grouped. This ungrouped  
> > > > > > user could then register a new HEW (or case) in CloudCare, then work could  
> > > > > > be done to properly group the HEW into the appropriate region and create a  
> > > > > > mobile user to link to that new case after the initial registration. This  
> > > > > > has worked fine.
> > > > > > 
> > > > > > Where we have been having issues is to modify an existing case. Since  
> > > > > > the ungrouped user is 'new', it does not have all of the HEW data (or  
> > > > > > cases) that the regional users have -- therefore, there is no way to select  
> > > > > > the appropriate HEW (or case) to modify. And if we try and modify HEW data  
> > > > > > (or a case), we receive an error message notifying us that group[ed] users  
> > > > > > can not make such changes in the CommCare system at this time.
> > > > > > 
> > > > > > Have any of you run into a similar issue? Do any of you have insight  
> > > > > > and/or suggestions on this issue? Please advise.
> > > > > > 
> > > > > > Thank you and if you require more information or clarification, please  
> > > > > > do not hesitate to let us know.
> > > > > > 
> > > > > > With much appreciation,  
> > > > > > Nadi Nina Kaonga (on behalf of colleagues)
> > > > > 
> > > > > --  
> > > > > Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)
> > > > 
> > > > --  
> > > > You received this message because you are subscribed to the Google  
> > > > Groups "commcare-users" group.  
> > > > To unsubscribe from this group, send email to  
> > > > [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).  
> > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > > 
> > > --  
> > > You received this message because you are subscribed to the Google Groups  
> > > "commcare-users" group.  
> > > To unsubscribe from this group and stop receiving emails from it, send an  
> > > email to [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).
> > > 
> > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > 
> > --  
> > You received this message because you are subscribed to the Google Groups  
> > "commcare-users" group.  
> > To unsubscribe from this group and stop receiving emails from it, send an  
> > email to [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).
> > 
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![Nadi\_Kaonga](https://dimagi.b-cdn.net/letter_avatar_proxy/v4/letter/n/65b543/32.png) [@Nadi\_Kaonga](https://forum.dimagi.com/u/Nadi_Kaonga)\
**Post date:** [January 30, 2013, 2:35pm UTC](https://forum.dimagi.com/t/requesting-help-insight-identifying-work-around-s-for-modifying-cases-using-group-ed-users/1290/8 "2013-01-30T14:35:28Z")

</div>

Thank you, Ray. We will definitely try and let the CommCare User Community  
know how this progresses.

With much appreciation,  
Nadi

 ![](https://dimagi.b-cdn.net/uploads/default/original/1X/100b9c74de82929ada11cf0f0f8f48b07069d409.png)

> **···**
>
> On Jan 29, 2013 8:20 AM, "Ray Brunsting" wrote:
> 
> > Re: "_With your custom case-sharing setting, have you been able to easily  
> > modify cases?_"  
> > While it has been working fine in testing, we don't yet have any field  
> > experience with case-sharing. I'd be interested to hear how your final  
> > design works out.
> > 
> > Best regards, Ray
> > 
> > On Mon, Jan 28, 2013 at 9:02 PM, Nadi Kaonga [nkaonga@gmail.com](mailto:nkaonga@gmail.com) wrote:
> > 
> > > Dear Ray,  
> > > Thank you very much for the feedback and the information. With your  
> > > custom case-sharing setting, have you been able to easily modify cases?
> > > 
> > > Dear Cory,  
> > > That is not exactly the problem, but may work towards the solution. My  
> > > only concern is if we re-assign cases to another user (from the region  
> > > user) and then modify the case, would that alter any of the form  
> > > submissions that that case has made? Please advise.
> > > 
> > > Thank you both and we are looking forward to hearing back from you.
> > > 
> > > All the best,
> > > 
> > > --  
> > > Nadi Nina Kaonga
> > > 
> > > On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue [czue@dimagi.com](mailto:czue@dimagi.com) wrote:
> > > 
> > > > Hi Nadi,
> > > > 
> > > > I'm having a hard time totally understanding the exact use case/problem  
> > > > you're describing, but I think it's possible that it boils down to  
> > > > something quite simple:
> > > > 
> > > > How can I assign a case (HEW) from one group (region) to another in  
> > > > CommCare HQ?
> > > > 
> > > > I know you've been using cloudcare for most of your workflows, but  
> > > > possibly the reassign cases tool[1] will be able to do this for you?
> > > > 
> > > > Apologies if I've vastly misunderstood what you need to do and gotten  
> > > > this all wrong, and please feel free to clarify.
> > > > 
> > > > thanks,  
> > > > Cory
> > > > 
> > > > [1]  
> > > > [Log In - Dimagi Confluence](https://wiki.commcarehq.org/display/cctroubleshoot/914.++Reassign+Cases)
> > > > 
> > > > On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting [ray@tula.org](mailto:ray@tula.org) wrote:
> > > > 
> > > > > While I'm not sure if this will help (or simply cause confusion), the  
> > > > > image below illustrates the design we have settled on for a similar  
> > > > > scenario.
> > > > > 
> > > > > I think the key difference between your design and this one is that we  
> > > > > decided model each community as a CommCare case, rather than each CHW. We  
> > > > > create one sharing group for each community and put the CHW and health post  
> > > > > nurse into this group. The design allows us to put as many users as  
> > > > > desired into each sharing group --- essentially changing the list of people  
> > > > > providing care to any community. Each community case is owned by the  
> > > > > sharing group created for that community and each sub-case of the community  
> > > > > has been setup to inherit the owner of the community case.  
> > > > > [_note_: the auto-inheritance of ownership require custom-coded xform  
> > > > > code; the Wiki [1] includes some documentation to handle situations where a  
> > > > > user belongs to more than one sharing group]
> > > > > 
> > > > > This seems to make it easier to handle situations where CHWs are  
> > > > > assigned to more/less/different communities, although other scenarios could  
> > > > > become more challenging to address.
> > > > > 
> > > > > Cheers, Ray
> > > > > 
> > > > > 1 -  
> > > > > [https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups](https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups)
> > > > > 
> > > > > [image: Inline image 1]
> > > > > 
> > > > > On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga [nkaonga@gmail.com](mailto:nkaonga@gmail.com)wrote:
> > > > > 
> > > > > > Dear Fellow CommCare Users and Implementers,  
> > > > > > We hope this finds you doing well. We are writing to request your  
> > > > > > thoughts and insights on group[ed] users in CommCareHQ. [Apologies in  
> > > > > > advance for the lengthy post, but wanted to provide as much detail as  
> > > > > > possible.]
> > > > > > 
> > > > > > We are working on a project in Ethiopia that requires regional users  
> > > > > > for a catchment area and individual users within that catchment area. The  
> > > > > > set-up is such that the individual users, who are Health Extension Workers  
> > > > > > (HEWs), are mobile users, and for each mobile user, a case has been set up.  
> > > > > > The case represents the individual (HEW) and includes key data points like  
> > > > > > their name, location, mobile phone number (if available) and health center  
> > > > > > that they work in. The regional users are office-based data entry personnel  
> > > > > > who have access to the same forms but use CloudCare and to submit the form  
> > > > > > on behalf of the HEW.
> > > > > > 
> > > > > > To submit forms on behalf of the HEW, the regional user is linked to  
> > > > > > each of the mobile workers and the corresponding "case". The regional user  
> > > > > > then selects a case in CloudCare and is able to open the form under that  
> > > > > > case and enter the data and submit.
> > > > > > 
> > > > > > Therefore, we have the regional user linked to each of the individual  
> > > > > > users for that region. Hence, group[ed] users.
> > > > > > 
> > > > > > However, we have found that registering and modifying a case (i.e., an  
> > > > > > HEW relocates to another health post in the same region) as a regional user  
> > > > > > has posed problems. Since the regional user has been grouped, an error  
> > > > > > message pops up to notify us that grouped users can not submit such  
> > > > > > modifying information.
> > > > > > 
> > > > > > To address this problem--at least for registering new HEWs (or cases),  
> > > > > > we thought we could set up a new user that was not grouped. This ungrouped  
> > > > > > user could then register a new HEW (or case) in CloudCare, then work could  
> > > > > > be done to properly group the HEW into the appropriate region and create a  
> > > > > > mobile user to link to that new case after the initial registration. This  
> > > > > > has worked fine.
> > > > > > 
> > > > > > Where we have been having issues is to modify an existing case. Since  
> > > > > > the ungrouped user is 'new', it does not have all of the HEW data (or  
> > > > > > cases) that the regional users have -- therefore, there is no way to select  
> > > > > > the appropriate HEW (or case) to modify. And if we try and modify HEW data  
> > > > > > (or a case), we receive an error message notifying us that group[ed] users  
> > > > > > can not make such changes in the CommCare system at this time.
> > > > > > 
> > > > > > Have any of you run into a similar issue? Do any of you have insight  
> > > > > > and/or suggestions on this issue? Please advise.
> > > > > > 
> > > > > > Thank you and if you require more information or clarification, please  
> > > > > > do not hesitate to let us know.
> > > > > > 
> > > > > > With much appreciation,  
> > > > > > Nadi Nina Kaonga (on behalf of colleagues)
> > > > > 
> > > > > --  
> > > > > Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)
> > > > 
> > > > --  
> > > > You received this message because you are subscribed to the Google  
> > > > Groups "commcare-users" group.  
> > > > To unsubscribe from this group, send email to  
> > > > [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).  
> > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > > 
> > > --  
> > > You received this message because you are subscribed to the Google Groups  
> > > "commcare-users" group.  
> > > To unsubscribe from this group and stop receiving emails from it, send an  
> > > email to [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).
> > > 
> > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > 
> > --  
> > Ray Brunsting, CTO, Tula Foundation / [www.tula.org](http://www.tula.org)
> > 
> > --  
> > You received this message because you are subscribed to the Google Groups  
> > "commcare-users" group.  
> > To unsubscribe from this group and stop receiving emails from it, send an  
> > email to [commcare-users+unsubscribe@googlegroups.com](mailto:commcare-users+unsubscribe@googlegroups.com).  
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
