SharePoint administrators at my (very large) organization recently blocked access to SharePoint Designer for 'inexperienced' users, citing not the burden of support (they don't offer it anyway), but the site-wide risk that actions by such users may pose. Asked for specific examples of such actions, an administrator pointed to (site-wide and presumably dramatic) performance hits that occur when large lists are created en masse and then (a) edited in datasheet view, or (b) have all their items modified by workflows. (I.e. a workflow going through all items in the list...?).The examples leave me unconvinced about the ban's necessity - my suspicion is that administrators can't be bothered with such a simple prevention exercise as compiling a 'what not to do' list - but maybe tougher ones exist? From administrator's perspective, what damage can a SPD-armed rogue/newbie in charge of a corporate sub-site inflict on other sites? Thank you.

Just to clarify: the question is not about how a sub-site owner can mess up his own site with SPD, but how he can create an externality for others. (The administrators in question do not provide support, and can only back-up/restore one's site).

Just to clarify: the question is not about how a sub-site owner can mess up his own site with SPD, but how he can create an externality for others. (The administrators in question do not provide support, and can only back-up/restore one's site). well, sub-site owner can slow down entire site collection performance by create bad-designed workflows, that's true, but my vote is for SPD anyway but under some administration audit

As I say, i love Microsoft products, but just for sake of question, refering to below post (It's not all mine)http://geekswithblogs.net/SoYouKnow/archive/2009/03/29/sharepoint-designer-ndash-a-definite-maybe.aspxI say Again, Sharepoint Designer is a Boon but must be used carefully. Also, I think this is much on this topic and should be good enough to understand.Thanks! I LOVE MS..... Warm Regards, Kshitiz Posting is provided "AS IS" with no warranties, and confers no rights.

'bad-designed' how? That is a very loaded question, but in general they mean poorly designed workflows that consume too many resources, large lists that the creator lists every column as an index (I have seen it. ugh.), users that think SharePoint lists would be a good replacement for their poorly designed Access database, and the list goes on and on.The risk is that although SharePoint is an excellent self-service platform for small customizations by the user community, if that user community doesn't have the background and knowledge to correctly design their customizations, they can become a detriment to farm performance and the user experience. Also, users tend to attempt to do too much themselves. If someone isn't keeping an eye on things to make sure that there is some sort of control over what is "user buildable" and what really should go to the development team, then all of the sudden you have these massive "applications" constructed that are a delicate weave of interactions that have no ability to weather change. You see it happen with Excel and Access as well.It really isn't due to any malicious intent of the users or lack of support from IT. It is really a failure of the management to realize that with systems like SharePoint you have to be willing to constantly evaluate how the users are making use of the platform and how those things can be extended for greatest effectiveness. A good example is if someone puts together a list and a little workflow to help them with part of their job and other users see it and start suggesting additions to it so that it can help them with their job. If management doesn't allow IT the resources to take over the project and properly develop the application, the users will attempt to make the changes themselves. So what this all boils down to is the easy answer for IT is ban SPD to avoid having to deal with the headaches. The good solution is putting in place the governance to realize when SharePoint customization and development rises to the level of a project and merits funding within the organization. This is usually a hard thing for managers to wrap their heads around because they don't understand that SharePoint is a platform for constructing a working environment, not a complete solution out of the box.

I feel there's still has not been enough specifics - this one may be the only one, in fact. > large lists that the creator lists every column as an index "Bad workflows" have been mentioned, but examples not offered.Let me put it this way. A site administrator says to a newbie site owner: "If you use Designer, you are on your own. I am not going to advise you on architecture or debug your code. My only concern is that you do something that spills over outside of your site, and affects other sites. So, think hard and give me a shout if you plan to do any of the following: <?> '.BTW, it's odd how even in the SharePoint book (published by Wrox and) authored by SP MVPs one sees opposite opinions about "ghosted vs. unghosted".