When cutting over from our legacy database, I approved for the migration team to populate the Church Membership field endpoint within ChMS with constituent parish registration status (Registered or Not Registered). In hindsight, I should have had the data mapped with what now serves as our secondary constituent codes (Active, School Family, Contributor, for examples), which more accurately reflect their current status with our parish community. By going with our original Registered/Not Registered mapping, our staff is now confused when viewing the Constituent Summary reports.
What fields are you trying to update via the import feature? And are you doing a self-import, or working with our migration's team to import your data? We have several of the fields such as Membership status already setup with endpoints for our migrations team to import into, so want to make sure we understand what you're trying to accomplish here.
Jason Godin
Jason, I'm going to schedule a call with you to make sure I understand what is going on here.
This is a post-migration, self-import idea.
When cutting over from our legacy database, I approved for the migration team to populate the Church Membership field endpoint within ChMS with constituent parish registration status (Registered or Not Registered). In hindsight, I should have had the data mapped with what now serves as our secondary constituent codes (Active, School Family, Contributor, for examples), which more accurately reflect their current status with our parish community. By going with our original Registered/Not Registered mapping, our staff is now confused when viewing the Constituent Summary reports.
What fields are you trying to update via the import feature? And are you doing a self-import, or working with our migration's team to import your data?
We have several of the fields such as Membership status already setup with endpoints for our migrations team to import into, so want to make sure we understand what you're trying to accomplish here.