Former Solicitors

Options
Our organization is just beginning to assign solicitors en mass in RE, but there were some assigned in the past. I am also trying to set a standard and develop SOPs for future of data entry. I do not like to delete information, so I do not want to delete former solicitors. Currently, we have 4 solicitor types: Primary, Secondary, Volunteer and Former Solicitor.


My question is if anyone has experience using the "Former Solicitor" type (of course with an end date) vs. just using the end date.


I forsee many issues with just entering the "to" date. Especially since all of our queries and exports are set up to export solicitor by type and not date. I also think that it might be decieving on the relationship tab, at first glance. I'd rather not rely on people looking at the to date, but the type of Former Solicitor. 


I am about to let folks into RE:NXT and am trying to determine whether or not to take away rights for fundraisers to assign solicitors and instead leave it up to me as the DBA. If fundraisers have edit rights, they can very easily just "end" assignments from NXT, which just seems dangerous to me (even if I restrict rights to just 2 directors). 


Any advice? Does anyone this using the "Former Solicitor" type is superflous and creates more work than needed? Thank you for your help!
Tagged:

Comments

  • Heather,


    Totally not superfluous, in my opinion.


    We have "former" versions of all of our solicitor types:

    Prospect Manager

    Former Prospect Manager


    Secondary Manager

    Former Secondary Manager


    etc....


    We use from and to dates as well so we know the timing of the assignment.  And we add a note on the relationship when the solicitor is assigned and ended (that way when the solicitor asks why, we can say because you - or your manager or Solicitor X - said so!) Using the Former version allows us to track the history of who managed the prospect and when. 


    I don't believe you can filter on export to include only solicitors without a "to date", it filters only on the type of solicitor.  So, it also allows us to "filter" which type of Manager we want to export.  We can choose to only export the Prospect Manager, Secondary Manager or whatever, whicout exporting the Former equivalents.


    We have a rule at my office.  Only I'm allowed to change assignments.  In theory, others could, but they're not supposed to - and in this, they listen to me :-)  And they have to give me a (good) reason why they want the change.


    Hope this helps,


    Shani
  • Thank you, Shani! That is exactly how I would like us to function, though I am open to other perspectives. I just find it much easier when pulling solicitor data. Your answer definitely helps, as it gives me backup for when the officers come to me asking why they can't mess with solicitors anymore :) 
  • Glad I could help.


    Another reason it's helpful to have control over changes is that if everyone is releasing their own prospects, then no one is tracking what is newly available, 


    Also, the way we process these changes, there are several steps.  And since no one wants to have to do a multi-step processs, they'd rather leave it to me :-)


    Because it's not just flipping the solicitor type and adding an end date.  It's adding the note.  And the prospect status has to change.  Which sometimes requires a consitituent note to be added explaining the new status...So given all that - they'd rather have me do it all.
  • I also prefer to use former codes. It is not an ideal when it comes to actual database management practices but becuase RE is not well designed to export only the "active" assignments I have found former to be extremely helpful. It also does help on the relationship screen to identify active assignments.


    I have presented before at BBCON and will be presenting again at the K-12 conference in July about setting up a database auditing system to regularly find errors such as someone who put an end date on a solicitor and did not change the type to former. I think creating this kind of system is preferable to simply saying "I'll do it myself". Train them, check regularly to see if anyone does it wrong, go back to that person, re-train if necessary, and have them fix the error.
  • I have walked into Orgs and inherited whatever old Solicitor system they may have had or started and not maintained.  No -- you cannot delete that info, it could be important and telling down the line in regards to relationship(s) with that constituent.


    My solution has been to pull them all into a query and globally add an End Date to the relationship.  Say, the last day of the last FY.  Then you can start new and fresh with whatever system for Solicitor assignments that you are now establishing. 

    Have found, because folks come and go, and assignments change, that it has worked best to utilize the start and end dates for each FY. 

    So even if it ends up that the same person gets assigned the next year, they just are added as a new solicitor with new FY dates for start and end.  That way, all of those fields are filled in at the same time on the solicitor relationship, and you only have to make a change if something changes mid year.


  • While you can't filter an Export on Solicitors without a "To Date," Export does have a date range capability.  We had been changing to "Former Solicitor" (only one "Former" type), but it was causing problems when running custom reports comparing current assignment to prior history, so we've shifted to just adding the "Date To."  It also avoids the confusion of "Does that former date range mean that's when they were active or when they were former?"


    To help viewing only the active Solicitor(s) on the Relationships tab, we use a Legend color of a pale grey for any "Inactive relationships."
    450b7f830b3203a954f14bb31c17a4dd-huge-in
  • I love the color legend and I do that too.


    And while export does have date range functionality it is FAR from intuitive and does not allow for (CurrentDate) so no matter who or when the export runs you ge the solicitors active on that date. Each time it is run you need to check that date and update it. How to do that for some less experienced users (and even for me on some days) is a bit confusing. When I haven't done it for a while I have to go to Knowledgebase and look it up.
  • Thank you for all of your thougtful answers. This helps a lot. I think I will still use the "Former" type and end date, train the officers and staff, continue to pull by type, audit for mistakes and use color coding. So a combination of them all!
  • I've gone the other way here...... we had so many solicitor changes as people were moved around it was a mess when you opened the relationships tab.


    We've chosen not to use Former, and I delete the solicitor relationship when we no longer use.  We aren't as concerned as to the "name" of the individual formerly assigned - as we have had a lot of turn over.  We are Higher Ed and assign by faculties.  Every time someone wants an assignment - they email me & I assign but I also create an action "assignment requiest" which lists who requested assigned & for what faculty and then their rationale.  These are kept.


    Once they are assigned they also have a proposal record - with the faculty & solicitor on the proposal, which is never deleted.  The solicitor may change but the faculty remains.  If a new faculty was taking over the assignment - we would change the status of the proposal to removed, with a proposal note indicating why it was made inactive & create a new proposal for the new faculty assignment - which would have come through me & a new action created.


    So far this has worked and we haven't had any need to use former solicitor relationship types, its easier to query and export.  


    I know I go against the grain of many who don't like to delete any information - but we felt we had this covered in other areas.

    Jacki

Categories