Share
ReportI've got a Dynamics instance that tracks applications into a program and then actual enrollments into that program. Not everyone who applies will be enrolled but we still want to track all of those applications - whether they were enrolled or not.
I originally set this up as two separate entities: application and enrollment and used workflows to enforce a 1:1 relationship. I come from a database background, so I set it up that way because, to me, that was "the right way" to do it. It works nicely, but now watching users trying to remember whether they should be looking at applications or enrollments, I'm wondering if I should have just set up one entity with both the application and enrollment forms on it, then show or hide those fields based on whether the applicant actually enrolled.
I'm at a point right now where there's no enrollment data, so I could relatively easily switch approaches, so I'm trying to come up with the pros of each approach. So far, this is what I've come up with:
Two entities:
- smaller entities so some space savings for those applicants that aren't enrolled (we're talking 10 thousands of records, though, not millions, so not sure how big a deal this would be)
- can lock down creation of that enrollment entity to specific security roles
One entity:
- more straight-forward for user
- could more easily accommodate other business units who might not have a formal application process and would just want to go straight to enrolled
I'm interested in how others have made this decision: have you chosen to go with one or two entities and how did that decision work out once it went into use?
*This post is locked for comments
All responses (
Answers (
291,269
