Page MenuHomePhabricator

Request for improvement to prospecting system to track moves management
Open, HighPublic4 Estimated Story PointsFeature

Description

MGFE uses the “MG Stage” field in Civi to track donor movement along the gift cycle. Our goal is to be able to report on how long an assigned donor has been in each stage. This would help us monitor donors to ensure they continuously move through the major gift pipeline.

As discussed during Civi Fortnightly (Feb 19):

  • We want to empower MGOs to change the stages of donors in their portfolio
  • It is helpful to see when they made the change and who did it so we can see how long the supporter was in that stage prior -- we would be reporting on this for moves management
  • We would use a hook to capture that change being made & create an activity when they do linked to that user
  • Option to click to change the stage -- Wenjun said this could be automatically added to an activity
  • Activity will need custom fields from the from -to stage -- Eileen
  • Need to keep Joseph in the loop for reporting

Details

Due Date
Mar 1 2026, 5:00 AM
Related Changes in Gerrit:

Event Timeline

@DBautista-WMF I had a couple questions on the details for this task:

  • Rationale field: Will this be commonly used (so we'd ideally want it to be presented to the user whenever a change is made) or something that we just want available but could be added to the activity after making the change (which would be made more feasible by point three here, if it could be an editable field in a table of activities)?
  • UI to make the change: I see the request for a one-click option. Is this something we'd want to do with buttons (Change to: Qualification, Cultivation, etc) or would it be simpler to have an edit in place select field (so you'd click to make the field editable, then make the change from the drop down)?
  • Visibility of changes: Would we want to make the history of stage changes visible directly on the Prospect tab or would there a link the user would click to pop up the change history?

@Lars thanks so much for your patience as I think through this task a bit more.

  • Having the rationale field present as an editable field could work. I don't plan on requiring it to be completed when updating the stage. At this time, I'm more interested in recording when the change took place.
  • A drop down selection would be sufficient.
  • As for question 3, if we wanted to view the history of changes on the prospect tab, would that be formatted in a table as mentioned above? With dates listed for each change?

@DBautista-WMF That sounds good. For the visibility of changes, we could definitely add a table on the Prospect tab, below the existing information. It sounds like we would want each row to look like:
Date | New status | Who made the change

@DBautista-WMF When would (optimally) the team start using/benefiting from this (e.g next FY, early next cal year?)

@AKanji-WMF Thanks for asking. March/April this FY if possible.

AKanji-WMF renamed this task from Request for improvement to prospecting system to track moves management to Request for improvement to prospecting system to track moves management.Oct 24 2025, 8:00 PM
AKanji-WMF set Due Date to Mar 1 2026, 5:00 AM.
Damilare set the point value for this task to 4.Feb 5 2026, 5:55 PM
Lars removed Lars as the assignee of this task.Feb 24 2026, 8:48 PM
Lars triaged this task as High priority.Tue, May 26, 4:07 PM

[[ https://github.com/civicrm/civicrm-core/pull/35820 | Upstream PR ]]adding contact pre and post hooks to custom field editing inline to make this possible.

Also, after this is in place, we can backfill the most recent change for each contact with a current status from the log table, so we have a starting point for everyone.

@DBautista-WMF Here's what I have put together currently, which will sit at the bottom of the Prospect tab:

image.png (762×2 px, 167 KB)

Does this make sense to you? Does the location work?

I haven't done anything custom for the rationale yet, but my thought is that because it seemed like it wouldn't be commonly used, we could just put the rationale in the Details field for the activity and avoid adding a custom field. You can do this by clicking the status in this table, which pops up the activity edit form. We could add a column to show the rationale in this table if you want. I think if we later find we want a rationale field that the user is prompted with on making a change, we should handle that in another Phab as it will require a new form.

Let me know if you have any thoughts before I finalize this.

Thanks for your work on this @Lars, I have a few questions.

Would the user update process be as follows:
User changes the MG stage field (currently located at the top of the prospect tab), which is then reflected in the MG stage history table; to add rationale the user goes to the table to click into the stage which pops up the activity edit form

Would the activities only appear on this table? Or also on the activities tab?

Could the table sit in its own block on the prospect tab?

@DBautista-WMF Yes, that's the current flow. If the rationale is going to be added more than occasionally, we should probably add a form that users would use to change the stage and add a rationale at the same time. I understood from the above that we didn't need this for V1 at least, but if we do, let me know.

These activities do also appear in the activities tab (the activity type is MG Stage Change and the subject shown is "Changed from X to Y" with the Added by being the person who changed it).

I'm not sure what you mean by sitting on its own block. Currently, there is a the Prospect block and this would sit right below that.

Great, thank you. Let's add a form. After thinking about it some more, I'd like to capture rationale when the change is made.

Also, below the prospect block works for me.

@DBautista-WMF I'll look into the form option, but it does add complexity, so we might want to deploy this as we have it now so that you can start collecting data, with no change needed to how users currently make changes, and then add a form as a follow up.

Would users typically be changing just the MG Stage or would they usually be changing multiple fields on the Prospect tab at the same time? In other words, can we make this a standalone form that the user clicks that only gives them the option to change the stage and enter their reason or does it ideally live within the existing Prospect edit form? The former is simpler and the latter a little more complicated.

@DBautista-WMF One option if users are typically changing multiple fields on Prospect at once would be to add a "Last MG Stage change rationale" field immediately below the MG Stage field. This would always store the most recent change reason, while the reason for each specific change, current and historical, would be stored on the MG Stage change activities. When the user changes the selection in the MG Stage dropdown, the Last MG Stage change rationale field would be immediately cleared — and this visual change should act as a prompt for the user to enter a new reason.

Change #1298349 had a related patch set uploaded (by Lars SG; author: Lars SG):

[wikimedia/fundraising/crm@master] Add MG Stage Change activity type with custom field "Changed to"

https://gerrit.wikimedia.org/r/1298349

@DBautista-WMF One more thing: I'm working on the backfill and will create all past activities that would have been created in the past for contacts who currently have a MG Stage. Do we care about contacts who previously had an MG Stage but do not currently have one (there are 162 of these)?

@Lars thanks for sharing options. I think users will likely only change the MG stage, not multiple fields at the same time. It doesn't need to be on the prospect edit form, so it can be a standalone form as you described.

Also, no need to create activities for the 162 that don't currently have a field. Thanks for asking!