Do I Need a New Page?
Because MinistryPlatform has an open architecture database model, you can extend the database by creating new tables and deploying them as Pages and Sub-Pages. The main reason for doing this is to track additional information that is unique to your church.
You can extend the MinistryPlatform software application framework without having to write code or recompile the application. As a result, your new pages need to be defined in the setup area, but they do not necessarily need to be added by ACS Technologies or a software developer.
Please review our Help Center or contact your SPoC for specific instructions on how to create a new page or otherwise extend the Platform. The following pages are intended only to walk you through the process of planning a new page.
Ask the Right Questions
Here are some questions you can ask when deciding if a new page should be created. We'll use the example of a church who wants to track their "Elders".
This is the thing you want to track. Elders: Officers of the church who is tasked with specific shepherding responsibilities.
- There are nearly 300 elders at any given time in this church.
- These are different types of elders.
- Each elder is supervised by a "Supervising Elder".
- There is a relationship between elders and the people and/or families they shepherd.
- There is a ministry department that oversees and manages these elders.
- Elders serve for terms with defined start and end dates.
- Elders can take a sabbatical.
- This is very high priority to the church.
- An existing ministry is struggling to manage with existing structures. They have already promised to manage this new page.
- There is a lot of special data related to elders that doesn't apply to other groups/group roles:
- This might imply special helper pages "Lookup Values" like Elder Type. Remember, any drop-down lists on your new Elder page need come from another page.
- Elders need to be assigned to households: **
- Note that this implies a foreign key will be added under Households.
- This implies page views on the households page to help manage the foreign key.
- Elders need to submit confidential notes related to their interactions with those they shepherd: **
- This implies a sub-page called for "Elder Notes" that itself is a main page.
- If there are two new pages we probably need a new Section called "Elders".
- Elders need to be assigned a "Supervising Elder" and this relationship is not easily or clearly expressed right now in the database.
- Is "Elders" sufficiently broad for a new page? What about Deacons? Should I call this page "Officers" instead of "Elders"?
- Are there other churches that use different terms, but accomplish similar things? Maybe we should talk to ACS Technologies. If they have already built reports and tools around a similar semantic, adopting that semantic might save us time and money.
- Initially, migration from existing structures (groups or relationships).
- Post launch, the team will add or update.
- Long term, we need an app for elders to add notes (visits and calls made).
- Simplify the group structure for elders:
- Only one group is needed so we conform with best practices in MinistryPlatform (having a central list of everyone who is participating/serving/leading in groups).
- Cease tracking "Relationships" between elders and the individual contacts they shepherd as soon as we start assigning elders to households.
- Have I mocked up my summary/overview reports?
- Can I use existing reports (for example, Selected Labels)?
- Can I use existing core tools (for example, Contact Log Tool, New Message Tool)?
Data Structure
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.
- 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)
- 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, New Message Tool) and reports (Selected Labels, and so on).
- A custom modification to the routine that combines duplicate contacts.
- Foreign keys on existing pages to the new page (for example, Households.Elder_ID)
- Foreign keys to existing page (for example, Elders.Contact_ID)
- Page Views on your new page (for example, Current Elders)
- Page Views on other pages (for example, "Assign Elders" on the Households page)
- Helper pages (for example, Elder Notes, Elder Types)
- Sub-pages (for example, Elder Notes)
- Security Roles (for example, Elder Manager)
- Reports (for example, Shepherding Summary)
- Tools (for example, Mobile App for Elders to Add Notes)
- Workflow Processes (for example, Notice to Supervising Elder if an elder goes on sabbatical)