9 Responses

  1. Scott Andre January 12, 2010 / 8:14 pm

    I am curious to know if the folder metadata can be changed within a data view or datasheet when using 2010. I have spent some time this morning trying to get this to work using a folder content type but to no avail!

    • Sree V November 30, 2011 / 11:33 am

      Were you able to find how to apply metadata to folders in 2010, which is possible to do it in 2007 using Datasheet view? Or is there a better way to do it?

      Thanks

      • Chris Poteet November 30, 2011 / 4:59 pm

        I didn’t know you could do that in datasheet view in 2007. You can apply default metadata for a folder in 2010 so that each document/item added to that folder will get default metadata.

  2. Chris Poteet January 12, 2010 / 9:55 pm

    Hi Scott. I just tried to do so, but my virtual machine for some reason isn’t configured for the datasheet view. Another 2010 mystery.

    I assume you mean changing the metadata that is associated with documents inside the folder and not actually adding metadata to the folder content type do you? It’s not a good idea to mess with adding to the default SharePoint content types.

  3. Shelley Petley June 13, 2011 / 1:44 pm

    The sole reason we found for using folders in SP2007 was for permissions. For example, we have a library which contains files from 4 divisions, and wanted someone from Division A to only see files from that Division. To accomplish this we set up 4 Division folders, with distinct permissions on each. Our default view displays the data without folders, to allow senior management to view data across divisions in one fell swoop. We were hoping that SP2010 would allow for setting permissions based on a Division metadata column rather that on a folder, but we are told this is not the case. Is there a better way of accomplishing this in SP2010?

    • Chris Poteet June 13, 2011 / 3:21 pm

      Thanks Shelley for the comment. I have a question. Do these divisions have their own sites? From what I can tell with your detail, I would’ve been inclined to separate the content into divisional sites.

  4. A small cog in a big machine January 29, 2013 / 7:52 am

    Reading this post is a revelation, but it raises a question (long preamble, but straightforward question, i promise).

    I work for a local authority that operates a multiude of differentiated services, and is halfway through rolling out a sharepoint based EDRMS.

    This process began about two years ago as a Corporate IT strategy, and has been led by a particular IT heavy department, with other departments now beginning to capitalise on that investment by rolling out Sharepoint section by section. The end intention is that this software, and surrounding policy, forms the basis of a legally admissable standard on data reproduction, thus allowing us to ditch paper records and paper working.

    Here I am, joining at the half-way point in one of those ‘other’ departments trying to select sections with a workflow compatible to the tools created for our original IT heavy department, in order that there be exemplars pour-encourager-les-autres.

    So, we have a self-developed client software that acts as a cross between a document viewer, and an administrative tool that allows incoming documents and records to be assigned to the appropriate person, whereupon it will be populated with the appropriate metadata necessary to prevent it disappearing into a morass of unstructured data.

    Great, except this client software is designed for a workflow that see’s a large volume of simple form based applications, simple requirments, and quickly dealt with, at which point it becomes an archived record. By way of contrast, we have a smaller volume on ongoing investigations that require living documents, supporting data in the form multiple images, emails, etc, that may be ‘active’ for six months or more.

    Much of this is manageable, our client software is already populated with enforced (and optional) meta-data tags before it can be declared as ‘processed’, paper gets scanned directly into sharepoint, and emails can be forwarded to sharepoint, however;

    The client software in this workflow is extremely daunting to non-IT staff, not least because [their] library view can quickly become unmanageable due to the sheer number of images, emails, and documents that sit in their inbox for the duration of the case. Images are currently added to sharepoint by email.

    To alleviate this problem I want to select “Save all attachments in folders grouped by e-mail subject” in Sharepoint. The result is that the email shows up in the client software as a sharepoint webpage showing both the email (which may provide important context to attachments) as well as the attachments themselves. One nice and neat entry in the client software which — outside task-specific applications that draw upon sharepoint resources — provides context to what would otherwise be a ‘soup’.

    Now when I suggest this let me reassure you of the following:
    1. I accept the ‘philosophical’ justification for enforcing meta-data tags over folders; we want to encourage users to adopt the sophisticated tagging system already in place, and not try to replicate the byzantine folder structures to be found across our existing network drives that they believe make so much sense.
    2. I accept the technical justification that it is difficult to apply metadata to objects within folders, and created complex nested heirarchies is likely to cause the advantage of sharepoint to be lost altogether.

    That said:
    1. This is not a user-created action, merely the result of an email aggregation fucntion within sharepoint itself, nor too is it user-controlled, just automated action creating a flat one-layer-deep folder structure for some items, so I don’t see it harming good-practice by users.
    2. In SharePoint 2010 we can specify metadata for a folder (which has always been a content type), and it will be propagated to the documents contained within the folders, so perhaps the associated objection is linked to our limited Sharepoint experience beginning with 2007 (now 2010).

    To a large extent we are constrained by the need to; follow the Corporate IT strategy (which we think is great), and to resuse client-software created for the workflow of another department (which I believe we can work around).

    So my question is this; given the workflow issues and policy constraints listed above, does my identified solution:

    a) Seem appropriate?
    b) Breach either of the two justifications given above for not using folders in Sharepoint?

    Any assistance is appreciated.

    Kind regards

    ASCIABM

    • Chris Poteet January 31, 2013 / 1:00 am

      So I don’t feel like I understand quite everything, but your situation might be a good one for document sets. At the very least a client like Colligo could help your users with the workflow.

      Maybe if I felt I understood more I would be more confident in my reply.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>