Although many organizations that use SharePoint employ internal developers to create custom solutions, every customer organization I’ve encountered in my ten years of SharePoint consulting has used external vendors for at least some development. These vendors include individual contractors, Microsoft Certified Partner firms like non-linear creations, and independent software vendors (ISVs) like Bamboo Solutions or K2.

Whether you use internal employees or third-party vendors, and whether an application is a simple web part or a complex business-process automation, you must not deploy it until you know it can be trusted. A poorly-written application can slow (or bring down) your entire SharePoint farm. It can destroy or corrupt data in your databases, or critical files on your servers. It can also circumvent your security, opening you up to all manner of attacks.

Below are six critical questions that you must ask any SharePoint developer, internal or external.

1. Is this a Sandboxed Solution?

Prior to SharePoint 2010, the only option available to the customer was to deploy every solution as a Farm Solution, where files are deployed to the file system and the code runs in the same execution space as SharePoint itself. If the solution is well written and behaves itself (for example, by NOT hogging all the server memory and crashing the SharePoint site it lives in), this is not a problem. But since the quality of custom SharePoint solutions is fully dependent on the developer/vendor, deploying a Farm Solution calls for a lot of trust on the part of the server administrator/customer.

Overcoming the customer’s understandable reluctance to deploy Farm Solutions was the driving force behind the introduction, with the 2010 product release, of Sandboxed Solutions. Sandboxed Solutions are web parts, Lists or other SharePoint features that run isolated from your SharePoint sites. By default, a Sandboxed Solution cannot access or affect anything outside of the local SharePoint site; external databases, web services, and the file system are all off limits. Your server administrators can apply limits and quotas to the Solution, so that if it misbehaves by (for example) hogging server memory, SharePoint 2010 will shut it down.

Your developers/vendor may complain that Sandboxed Solutions are additional work. They may say that they are too neutered and can’t do anything useful. However, for a solution that requires access only to the local sites, lists and libraries, the latter isn’t true. And Sandboxed Solutions can be given additional permissions safely by using something called Full Trust Proxies, which let your vendor’s code request specific rights, while remaining isolated from the SharePoint execution space.

Now that we have Sandboxed Solutions, a SharePoint developer’s first question (and yours) when designing a new feature should always be, “can I write this as a Sandboxed Solution?”.

2. If it’s not Sandboxed, does it run as fully or partially trusted?

Sandboxed Solutions are still quite new, and do require extra work, so they are not yet the industry standard (this will change very soon). And there will always be some solutions that can run only as Farm Solutions. You will still have occasions, then, when it will be acceptable to deploy a Farm Solution. But if your vendor or in-house developer delivers you a Farm Solution, you must know if it partially or fully trusted.

With a fully-trusted solution, your developer’s code can access the file system on your SharePoint servers, it can access the Windows Registry — it is pretty much an administrator. From a developer’s viewpoint, this is the fastest and easiest way to develop. But with the availability of Sandboxed Solutions and partially-trusted solutions, there are very few reasons for you to accept a fully-trusted solution.

A partially-trusted solution has no innate rights, and must be explicitly granted permissions (in a special configuration file called a Code Access Security policy) to do anything. The developer must provide this file, which you can inspect.

3. Does it use Elevated Privileges?

If for some reason your vendor must provide you with a fully-trusted solution, you must not deploy it until you understand everything it is going to try to do.

One of the key questions in the vetting process: does it use RunWithElevatedPrivileges? This is a SharePoint feature that is exactly what it sounds like. By default, when your vendor’s code tries to do something like access a SharePoint document, it impersonates the user browsing the page; the code can’t do anything the user can’t do. However, a fully-trusted solution (or a partially-trusted one granted the permission) can use RunWithElevatedPrivileges to temporarily impersonate an account that has Full Control of your SharePoint application.

RunWithElevatedPrivileges is a powerful tool that must be used sparingly, because it can circumvent your carefully-planned SharePoint security.

Something else that can circumvent your security is Feature Event Receivers.

4. Does it use Feature Feature Receivers?

A Farm (non-Sandboxed) Solution can include small bits of code that run when your server administrator installs or uninstalls a custom solution. For example, the solution may depend on the existence of an external database; a Feature Event Receiver can confirm that the database exists, and create it if necessary.

Feature Event Receivers enjoy full administrative privileges on your server farm, so it is very important that you fully understand what they are programmed to do.

5. Where does it store configuration settings?

Many applications need a place to store configuration settings (e.g., database connection strings, or an email address for alerts). If your vendor’s solution uses the main configuration file (web.config) for this purpose, you increase your risk because this file may be shared by hundreds of SharePoint sites on your farm, and the slightest typo can bring them all down.

In general, an experienced SharePoint developer will not provide you a solution that requires manual entries to web.config. Instead, a Sandboxed Solution will keep its settings in a local SharePoint list, and a Farm Solution will do the same or include a Feature (or Feature Event Receiver) that adds settings to the web.config file automagically on installation (and removes them on uninstallation).

6. Where does it log messages?

Finally, an experienced vendor will develop a solution with extensive logging. Even if the code has been developed defensively and tested thoroughly (two other things you need to ask about), even the best software goes wrong occasionally. When that happens in a production environment, you need to know exactly what happened so it can be diagnosed and remedied. An application can log messages to the Windows event log, a database table, the SharePoint Unified Logging Service, or a SharePoint List. Before you deploy the solution, you need to know which of these places it logs to, what kinds of messages it logs (is logging too verbose? Too sparse?), and whether the logging can be configured (is logging off by default? Are there different modes — Errors Only, Verbose, etc.?). If there is no way for you to get enough information when something goes wrong to at least understand what happened, without involving the vendor, this is a sign of a poorly-designed solution.

These questions are only a sampling of the kind of due diligence required of you as the owner of a SharePoint environment. As in any business relationship, the key ingredient is trust.