No. You may not rename database tables, fields, or stored procedures that are part of the core MinistryPlatform schema that came with your system or has been updated by ACS Technologies. You can rename custom fields you added or custom tables and pages, but do this carefully as any views, reports, or tools built against those original objects will break.

Never delete items in System Lookup pages. We don't recommend renaming them because you may not be able to find what you're looking for in this Help Center. You can generally add valuese, but there are certain system lookup pages like Contact Status and Group Role Types where this is a huge liability to your church's use of the existing reports and tools. Consequently, always ask before you add values to system lookups. It is expected and natural that your church would rename or add values to the pages under "Lookup Values".

This is unwise and should be avoided for all pages that came with MinistryPlatform. It's better to leave that page alone and create a filtered page (a copy of that page with a value in the Filter Clause). Changing the internal name of a page will not update reports and other hard-coded applications. Where possible and requested by our churches, we provide the church the ability to rename a value like "Congregation" on the external, public facing applications like the Portal.

You can do this, but it is unwise as it makes your system inconsistent with this Help Center. Doing this for your custom reports and tools is acceptable.

Always add a filter clause to your copy of the page. Having two unfiltered pages results in ambiguity for tools that dynamically draw the database using foreign key information from SQL Server and Page information in MinistryPlatform. Make sure people who will create advanced searches retain sufficient rights to the original, unfiltered page.

No. If you make changes to our RDL file or to an underlying stored procedure, then a future upgrade of that report may overwrite your changes. Instead, copy the RDL file and deploy it with a different name so that you will have "forked" or "cloned" the report and taken your copy of it out of the upgrade path.

Yes. See this article on how to edit fields for more information.

Yes and no. If the field is required, the field labels display as a question to be answered as a yes or no, and the default is always no.

For tri-state (nullable) bit field, the default is undefined, but you can change this in the database. In this case, the default value does not display initially, but when you save and display the record, the value changes to the default.

No, we would not recommend importing anything directly to database tables. That would not create all the needed records and linkages. If the people are already in MinistryPlatform, then you can add people to Groups using the Add button. However, if they are not in MinistryPlatform yet, then currently there is not a way to add several new people at once. The fastest way to manually add people is to use the Add/Edit Family Tool. You can also use the Group Finder on the Portal. You can direct everyone to sign up for Groups on the Portal. By doing so, they are added to the Group, and if new, are added to the Platform.

Yes, you can create a read-only page in the Platform from a database view. Examples include the Giving Unit Summary and User Rights & Restrictions.

In this case, the Auto Date still works because it is a trigger on the table.

Yes. See this article on how to edit a record's friendly name for more information.

This is most likely just the system needs time to update and recognize this new page. To move it along, we need to help MinistryPlatform know that something changed. One way you can do this is to edit the Addresses page in Setup Area > Pages and modify the description. Once you save any changes in the Pages section, MinistryPlatform reloads and re-reads all the MetaData from SQL.

Sometimes the system needs to track information in a field that does not need to display on the front-end, typically to help when processing, notifying, and so on. The underscore at the beginning of the field hides the field from users, making the field hidden and valuable sothe system to run smoothly.

Yes, it is possible to change a field length. For example, you could change the Notes field from nvarchar(500) to nvarchar(2000). We don't recommend exceeding 2,000 due to the strain it puts on the server. Contact Support if you're uncertain whether changing a field length is a good idea.

Yes, you can combine two fields into one in a view by adding SQL to the Field List. The SQL you would need to add to the Field List depends on which table or page the view is on.

You can find the metadata you're looking for in these two tables: dp_Sequences and dp_Sequence_Records. If you need help writing an SQL statement, we can do that as a Professional Service.

It is absolutely necessary to create a sandbox and test changes. While you can technically write changes directly into a Production system, it is very unwise to do so. Also, problems created by changes to your database - especially outside a sandbox - will incur a fee to correct.

Yes, you can set up your own jobs. That said, we do not recommend editing jobs created by MinistryPlatform. Your custom stored procedures must use a church-specific prefix other than "dp_". Any custom stored procedures using "dp_" as the prefix are deleted in subsequent releases.

This field is deprecated and is no longer in use by the system.

Yes. In general, you can do this in the Platform. There may be limitations on what you can do using this approach. To determine these limitations, youcan test in the database or the Platform.