Before you begin, you should carefully plan out your data structure. While it takes more time up front, you can be sure that you answer many important questions before you start down the path.
List the fields you think should be present on your new page:
-
Elder_ID (Int, Primary Key, Is Identify, Auto-increment by 1)
-
Contact_ID (Int, Not Null, Foreign Key to Contacts.Contact_ID)
-
Start_Date (DateTime, not null, when the Elder began his tenure)
-
End_Date (DateTime, null, when the elder ended his tenure)
-
Supervised_By (INT, null, recursive FK back to “Elder_ID”)
-
On_Sabbatical (Bit, Not Null, Default 0)
-
Domain_ID (INT, not null, must be present on pages in the platform that users will see)
Consider the impact of extending your database
-
Linking your page to Contacts, Participants, Donors or Users could require populating the Contact_ID_Field on the page record in the setup area so you can leverage existing tools (Contact Log Tool, Text Message Tool) and reports (Selected Labels, etc).
-
A custom modification to the routine that combines duplicate contacts.
Creating a page implies many other things may need to be created. Make lists!
-
Foreign keys on existing pages to the new page (ex. Households.Elder_ID)
-
Foreign keys to existing page (e.g., Elders.Contact_ID)
-
Page Views on your new page (e.g., Current Elders)
-
Page Views on other pages (e.g., “Assign Elders” on the Households page)
-
Helper pages (e.g., Elder Notes, Elder Types)
-
Sub-pages (e.g., Elder Notes)
-
Security Roles (e.g., Elder Manager)
-
Reports (e.g., Shepherding Summary)
-
Tools (e.g., Mobile App for Elders to Add Notes)
-
Workflow Processes (e.g., Notice to Supervising Elder if an elder goes on sabbatical)
