Do I Need a New Page?
This section will help you determine whether or not you need to create a new page, including asking the right questions and data structure.
Because MinistryPlatform has an open architecture database model, you can create new tables and deploy them as pages and tabs (sub-pages) to extend the database. This is mainly to track additional information that is unique to your church.
You can extend the MinistryPlatform software application framework without writing code or recompiling the application. As a result, you need to define your new pages in the setup area, but you don't necessarily need ACS Technologies or a software developer to add them.
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 sections 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 or 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 tab (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:
- We only need one group, so we conform with best practices in MinistryPlatform (having a central list of everyone who participates, serves, or leads 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 and overview reports?
- Can I use existing reports (for example, Selected Labels)?
- Can I use existing core tools (for example, the Contact Log Tool or New Message Tool)?
Data Structure
Before you begin, you should carefully plan out your data structure. While it takes more time up front, you may 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)
Consider the impact of extending your database. If you link your page to Contacts, Participants, Donors, or Users, you may need to enter information in the Contact_ID_Field on the page record so you can use existing tools and reports.
- 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)