<p><span style="line-height: 1.6em;">Jeremy, t</span><span style="line-height: 1.6em;">hanks for the prompt reply.</span></p>

<p><span style="line-height: 1.6em;">Your suggestions are good</span><span style="line-height: 1.6em;">, but I don&#39;t think they address my problem in a satisfactory way:</span></p>

<p><span style="line-height: 1.6em;">1. If I create a new Role called Deleted, I lose the information about the Role that the person occupied when they were removed.<br />
A new Status of &quot;Deleted&quot; would be preferable, but I don&#39;t think I can add that to the configuration?</span><br />
<span style="line-height: 1.6em;">Also, my guess is that I would have to manually exclude them from all Group Views?</span></p>

<p>2. Creating a new sub-group for 100s of Small Groups would be an administrative nightmare I think?. Also, although the historical information would be there, it would make aggregated and statistical reporting much more difficult if not impossible.<br />
<br />
<span style="line-height: 1.6em;">Maybe I&#39;m missing something here, but I must say I&#39;m quite surprised at the overall design decision to permanently delete *any* information from a database in this day and age.&nbsp;</span><span style="line-height: 1.6em;">I would have expected records would be simply marked as deleted, with the option to purge them at a later date should that become necessary.</span></p>

<p style="line-height: 20.7999992370605px;"><span style="line-height: 1.6em;">It&#39;s a pity if this is the case, because it really hampers the ability to provide good historical reporting. For example, what if I wanted to get a snapshot of the Group Membership at some point in the past? Or determine actual Group growth over the last few years (including people that have come and gone)?</span></p>

<div>Jeremy, are you a member of the dev team, or do you know who I should take this up with? I might be interested in adding this functionality to the system if the idea is well received.</div>

<p>Ok, thanks for your input Jeremy (2?).</p>

<p>Metrics are a good feature, but I don&#39;t think they can help if we want to write a new report that we haven&#39;t been calculating metrics for previously?<br />
We would like to move a lot of historical data to Rock if we adopt it, and we may want to write new reports that take advantage of historical data.<br />
Therefore, I prefer a design that never deletes data from the system except where absolutely necessary.</p>

<p><span style="line-height: 20.7999992370605px;">Obviously, switching to a retention of deleted records potentially impacts all aspects of the system, so I would like to know if the effort would be considered worthwhile by the design team, and also if the current system has unit tests that have sufficient coverage to ensure that nothing breaks in the process.</span></p>

<p><span style="line-height: 20.7999992370605px;">I have a pretty good knowledge of the backend elements of the technology stack you are using, so I could attempt this myself if it was approved in principal.&nbsp;But I&#39;ve only just starting evaluating Rock for our church, so I really don&#39;t have the knowledge to make the assessment myself at this time.</span></p>

<p style="line-height: 20.7999992370605px;">I&#39;m happy to put this in the suggestion box if that is the best way forward, but I&#39;d also like to chat to one of the developers about their estimate of the work effort for this and whether it is a shift in design approach that they would consider. Will the suggestion box route start this dialogue sometime in the near future?</p>

<p>Partly. The History table can provide the link to the Group and Person, but I&#39;m sure the Group Member Attributes would be deleted along with the Group Member record? Some of these attributes would most likely also be required for historical reporting.</p>

<p>Sorry, I can&#39;t give you any samples - our current ChMS doesn&#39;t support this either!<br />
However, I&#39;ve worked on other CRM systems that do provide this kind of history retention, and it can be very useful.</p>

<p>Here&#39;s a couple of simple use cases:</p>

<p>1. I&#39;d like to see a list of Past Members of the Group in the Group Details screen.<br />
(Past &lt;&gt; Inactive, because Inactive means they are still associated with the Group in some way)<br />
2. A report that shows a snapshot of who the Group Members were as at 1/1/2010.<br />
<span style="line-height: 20.7999992370605px;">An extension of this might be a report that shows the average size (ie. number of members) of our small groups in 2013 as compared to 2014.</span><br />
<span style="line-height: 1.6em;">3. A report that shows a list of all the people who have left a Group in the past 5 years, including their stated reasons for leaving (recorded in a note field attached to the Group Membership record).</span></p>

<p>In each of these situations, I need to know when the person actually joined the group and when they left.<br />
<span style="line-height: 20.7999992370605px;">(I don&#39;t think this can&#39;t be accurately achieved using the History Table, because the history table doesn&#39;t tell me when the person actually joined or left - it only give me the audit details of when the action of adding/removing was performed, which may be some time much later - especially in the instance of imported historical data).</span></p>

<p><span style="line-height: 1.6em;">In Case (3), I also need the Notes (custom) field associated with the Group Membership record - these details are not available once the record is deleted.</span></p>

<p>Does this help clarify?</p>

<p>The history of group members is certainly something we&#39;ve been talking about for awhile. It&#39;s not been added to the roadmap as it&#39;s still very much in the crockpot of how it will be implemented. Based on feedback we can move it up in priority.</p>