Hello Dieneke and Christopher!
It’s been a bit of an adventure over here. We’ve just signed on with a nonprofit specific financial services provider, so I’m expecting to be a bit busy onboarding with them for the next few weeks. After which, I can turn my full attention to completing the various program ingest and scheduling projects. Would you please illuminate on our remaining balance?
I’ve some sample data, attached. Our folks are working on resolving questions I have around workflow needs; mainly person records being associated with a procedural action, attached to the Project/Season/Program records.
The sample data may include items that do not yet exist, or may need to be matched to the proper name.
The exports taken recently used to create them included columns we don’t intend to use and some items are missing in one table while present in others.
Some concepts captured by Ron in the original schema need to be parsed by our folks before we try to implement them:
Requested By: Presumably the producer, but could this be someone else?
Responsible Staff: I’m unsure how this differs from Requested, but can imagine requested to be a client we’re producing for.
Approved By: I’ve some notes here suggesting that’s the person who processed the request, who completed the schedule reservation. Should be "Processed By" if the notes are accurate.
Promised By: Now I’m confused… would this be the staff producer? Would this be playback?
Some notes:
dam_contact_type might be fine as a list, not sure.
dam_is_series seems redundant, unless it’s needed for a reason I’m not seeing. I think we hid some fields when it was false, in the previous build.
Runtime fields need to be simplified to reference a list of specified lengths in minutes, and no need for optional manual entry.
The items which reference a person will need to be sorted, and might be ignored for now.
I want to remove the contact info columns since we’re moving to a contact database and ref’ing ids.
We need a place to have a default program number and program number. This would eventually be generated from business logic, for new records.
Seasons need a renewal priority column, to allow for sorting based on the policies we have. Business logic might help update these as we process requests.