Home - Alana Helbig

17/09/2009

Use the Contact Selector in InfoPath to get user details – no code required

Some people advised that this method wasn't working as well as it could. I have modified the steps in this post slightly and this should give you more consistent results regardless of whether you are using the browser or the client. Thanks again for your feedback.

Ah, my love affair with the contact selector continues J. Ever wanted to pull a specific user's details into your InfoPath form? It's pretty easy to get the current user's details. But try to get another user's details and it becomes pretty difficult. All of the solutions I have read up until now have involved code (and I don't like to code).

Well, recently I was doing some reading and I stumbled across this great blog by Clayton Cobb. It shows how you can get any details (department, office, manager etc) for any user you like and pull the data into an InfoPath form. How awesome!! I thought I'd extend Clayton's idea and incorporate the contact selector into the mix.

To get the most out of this post, you need to understand a couple of key concepts:

How to set up a contact selector in an InfoPath form. Check this blog out if you need help.
How to use the UserProfileService. Itay Shakury's blog can help you with this.

I would suggest reading and doing the steps in these blogs first before you attempt to go any further.

Ok, here we go.

I'm assuming that you have read the above 2 blogs and therefore should have the following already set up in your InfoPath form:

The contact selector
A data connection set up to the 'GetUserProfileByName' method

For this post, I'm going to get the user's manager and the user's department. I have set up my form so it looks like this:

And the main data source looks like this:

GET THE EMPLOYEE'S USER NAME WITHOUT THE DOMAIN

We are going to be passing the employee's user name into the 'GetUserProfileByName' method to extract the relevant department and manager. For this to work we need to extract the employee's user name, without the domain, from the 'AccountId' field in the contact selector.

Double click on the 'EmployeeUserName' field to open the field's properties

Click on 'fx' next to the 'Value' field.

Insert function

Select the 'substring-after' function

Set up your formula to look like this:

This is going to take everything after the "\" in the account ID field. So for example, if I enter my name in the contact selector the account ID will look something like this "MYDOMAIN\ahelbig". By using the substring-after value we are left with 'ahelbig'.

Click Ok and the Ok again.

Try previewing your form at this point and enter a name in the contact selector. You should see something similar to this:

GET THE DEPARTMENT

Now we can get into the fun stuff..... We will begin by extracting the department of the employee. All I'm doing here is using the steps in Clayton's blog to achieve this. Clayton has done such a great job of describing the why's so I'm not going to do that here. If you need more information, jump over into Clayton's blog.

First we create a rule that sets the 'AccountName' in the 'GetUserProfileByName' data source.
Double click on the 'EmployeeUserName' field in the main data source to open the field's properties

Click on 'Rules and Merge' and then click 'Add'
Give the rule a name such as 'Get Employee Info'
No condition is required
Click 'Add Action'
Leave the action as 'Set a field's value'
Click on the button next to the 'field' field
In the data source drop down select the GetUserProfileByName Data source
Expand out the groups and select the 'AccountName' field

Click on Ok
Click the 'fx' button next to the 'Value' field
Click on 'Insert field or group' and then select the 'EmployeeUserName' field
Click on ok and then ok again
Your action should look like this:

Click on Ok
Back in the 'Rules' window click on 'Add Action' again.
In the Action drop down box, select 'Query using a data connection'
In the 'data connection' field select the 'GetUserProfileByName' data source
It should look like this:

Click on Ok to save the action
Back in the 'Rules' window, we are going to add one more action. So, click on 'Add Action' again
Leave the action as 'Set a field's value'
Click on the button next to the 'field' field and select the 'Department' field
Click on Ok
Click on 'fx' next to the 'Value' field. Now this is where understanding Itay Shakury's blog comes in handy.
Insert a field or group
Click on the data source drop down and select the 'GetUserProfileByName' data source
Expand out the groups and select the 'Value' field.

Click on 'Filter Data'
Click on 'Add'
In the first drop down box select 'Select a field or group'
Select the 'Name' field from the 'GetUserProfileByName' data source

Click on Ok
Leave the condition as 'Is equal to'
In the last drop down box enter 'Department'
Your filter condition should look like this:

Click on Ok until you are back at the 'action' window. Your action should look like this:

Click on Ok to save the action
You should have 3 actions that look like this:

Note: It's very important that the actions appear in the order as shown
Click ok 3 times to save the rule.
Now is a good time to preview or publish your form and check that everything is working. Go ahead and enter a name into the Contact Selector and see the 'Department' field auto populate.

If you're anything like me, it was about this point in the process that I started to get really excited....

GET THE MANAGER'S NAME

If you have managed to get this far and everything is working ok, then these next few steps will be pretty straight forward. Basically, we are repeating what we have already done for department except this time we are going to get the manager.

Open the 'Get Employee Info' rule you created on the 'EmployeeUserName' field

Click on 'Add Action' again

Leave the action as 'Set a field's value'

Click on the button next to the 'field' field and select the 'Manager' field

Click on Ok

Click on 'fx' next to the 'Value' field.

Insert a field or group

Click on the data source drop down and select the 'GetUserProfileByName' data source

Expand out the groups and select the 'Value' field.

Click on 'Filter Data'

Click on 'Add'

In the first drop down box select 'Select a field or group'

Select the 'Name' field from the 'GetUserProfileByName' data source

Click on Ok

Leave the condition as 'Is equal to'

In the last drop down box enter 'Manager'

Your filter condition should look like this:

Click on Ok until you are back at the 'action' window. Your action should look like this:

Click on Ok to save the action.
You should have 4 actions that look like this:

Note: Once again, it's very important that the first 2 actions appear in order as shown - the other actions can be in any order

Click ok 2 times to save the rule

Test the form to make sure that the manager's user name is populating.

Now at this point, you really are done. Most people just want to know the manager for the purposes of some kind of workflow. For example, you may want to route this form to the employee's manager for approval. Technically, you have the manager's user name, which is enough and can be used to assign tasks and send emails to the manager using SharePoint Designer workflow or some other workflow tool. Personally, if my client wants the manager's name to be displayed on the form, or perhaps in email notifications, I don't like just having the manager's user name. I think it looks ugly. I would much rather have the manager's full name displayed nicely on the form and just use the manager's user name for the purpose of sending email notifications with workflow. Clayton's post shows very nicely how to achieve this by using the 'PreferredName' so definitely worth a look if you haven't already.

I know this was a long post but hopefully you have the idea. I've only shown you how to extract 2 pieces of information about the employee. Of course, you can use this method to extract any other bits of information as you need. Refer to the long list of user information that Itay Shakury's provides in his blog.

Some final notes:

You might also like to consider limiting the contact selector so that only one name can be entered. If you think this is necessary, click here to find out how.
Once again, special thanks to Clayton, who totally made my day when I read his blog.

Stay tuned for my final post which talks you through how to validate the name in the contact selector.

Posted at 5:21 PM by Alana Helbig | Category: InfoPath 2007 | Permalink | Email this Post | Comments (0)

31/07/2009

Validate the Contact Selector in InfoPath – Make the Contact Selector Mandatory (version 2)

Here is a very quick and simple method of making your contact selector in your InfoPath form mandatory.

There are plenty of blogs out there that describe how to set up the contact selector in your InfoPath form so I won't bother documenting that here. If you need help, check out this blog.

After you have added your contact selector to the form, it will most likely look something like this:

Your data source will look similar to this

Note: Check to make sure your contact selector is working correctly before continuing with this blog.

Firstly, add a new field to your data source called 'EmployeeName'. This will be the field that performs the validation check.

To add a new field, click on the "myFields" group in your datasource

Then click on 'Add new Field or Group'

Enter a name for your field and then click on Ok when you are done

After you have finished adding the field, your data source should look similar to this:
Next we are going to set the 'EmployeeName' field to equal the display name entered in the contact selector.

Double click on the EmployeeName field to open the properties

Set the default value of the field to 'DisplayName'
Now that the 'EmployeeName' equals the DisplayName all we need to do is set a validation rule on the EmployeeName so that it can never be blank.

Click on the 'Validation' tab in the EmployeeName field properties

Click on Add. Then set your validation rule as shown below.

Click Ok and Ok again to save the changes

I always put any validation rules for the contact selector on the 'EmployeeName' field rather than on the Contact Selector itself. My reasoning behind this relates to the validation error message that the user sees (below). Notice that it includes the name of the field that holds the error. 'Employee Name' makes it easy for the user to identify the field with the error. If you place the validation condition on one of the Contact Selector fields such as 'DisplayName' it is not very intuitive.

Another thing that you can do to notify your users of the validation error is to include an error warning next to the contact selector on the form canvas.

On your form canvas, insert a section and in the section enter "Cannot be blank"

You might like to highlight the text in red and make it italics so it stands out.

Double click on the section you added to open the group properties

Click on the Display tab and then click 'Conditional Formatting'

Click on 'Add'

Set the condition "EmployeeName is not blank"

Tick the 'hide this control' checkbox

The condition should look like this:

Click on Ok 3 times to save the changes

Publish your form.

Open a new form and you should see the error warning next to the contact selector name. If you enter a name into the contact selector, then the error message should disappear.

If you found this post useful, you may also find my post on limiting the number of names in the contact selector useful too.

Posted at 6:07 PM by Alana Helbig | Category: InfoPath 2007 | Permalink | Email this Post | Comments (0)

18/07/2009

Use the Contact Selector in InfoPath to get user details – no code required

This post has been moved.

http://www.myriadtech.com.au/blog/Alana/Lists/Posts/Post.aspx?ID=20

Posted at 4:27 PM by Alana Helbig | Category: InfoPath 2007 | Permalink | Email this Post | Comments (15)

17/07/2009

Validate the Contact Selector in InfoPath – Make the Contact Selector Mandatory

After I published this post, I had a couple of people comment that this method doesn't work as well as it should. While this method works fine in browser enabled forms, in the client, it is not so great. Here is a newer post I have just done which is a much simpler method for making your contact selector mandatory and works perfectly in both the browser and the client. Thanks to everyone who posted your useful comments… I really do appreciate your feedback.

Before reading this blog you may want to take a look at

My first post "Validate the Contact Selector in InfoPath – Limit the number of names entered"; and
If you're unfamiliar with the contact selector you may want to check this blog out

Have you ever tried to make the contact selector mandatory? I don't know about you, but I initially had some troubles with it. I tried making the 'DisplayName', 'AccountId' and 'AccountType' fields mandatory. I tried adding some validation to the same fields. Neither of these ideas worked. Then I realised, if I could somehow determine how many names have been entered in the contact selector, I should be able to add some validation conditions to ensure the field is never blank.

This concept is exactly the same as the method I used in my first post, just with slightly different validation conditions.

Follow the first 3 steps in my initial blog then:

Double click on the 'EmployeeName' field in the data source to open the field's properties.

Click on the validation tab and then click 'Add'

Set the condition "EmployeeNameCount is less than 1"

In the 'Screen Tip' field enter "Cannot be blank"

Your validation condition should look like this:

Click on Ok to save the validation and then Ok again to save the changes to the field's properties.
Publish your form, don't enter any names into the contact selector and then submit.

If you are using a browser enabled form, the validation error message you get should look similar to this:
As mentioned in my last blog, it's a good idea to include an error warning next to the contact selector on the form canvas, especially if you are using a client based form.

On your form canvas, insert a section and in the section enter "* Cannot be blank"

You might like to highlight the text in red and make it italics so it stands out.

Double click on the section you added to open the group properties

Click on the Display tab and then click 'Conditional Formatting'

Click on 'Add'

Set the condition "EmployeeNameCount is greater than or equal to 1"

Tick the 'hide this control' checkbox

The condition should look like this:

Click on Ok 3 times to save the changes

Publish your form.

Open a new form and you should see the error warning next to the contact selector name. If you enter a name into the contact selector, then the error message should disappear.

Pretty straight forward hey?

In my next post find out how you can obtain other details, such as department, office and manager, from the contact selector.

Posted at 4:55 PM by Alana Helbig | Category: InfoPath 2007 | Permalink | Email this Post | Comments (7)

Validate the Contact Selector in InfoPath – Limit the number of names a user can enter into the Contact Selector

I have to admit (even though it sounds really geeky) to my new love affair with the contact selector in InfoPath. I've always known it was there and have used it on numerous occasions but did find it a little bit limited. Lately, I've taken the time to actually look at the control properly and I've been pleasantly surprised with what I have been able to achieve. In my next few blogs, I'm going to cover some cool things that I have discovered with the control while at the same time hopefully answering some commonly asked questions for the InfoPath users out there.

This first post tries to answer the question – 'how can I limit the number of names that can be entered into the Contact Selector in my InfoPath form?' I've seen a couple of answers, none that are simple, some that even involve code. I'm no coder (and don't particularly want to be), so here is a simple solution that utilises the 'count' function and some validation conditions… yep, that's right, no code.

There are plenty of blogs out there that describe how to set up the contact selector in your InfoPath form so I won't bother documenting that here. If you need help, check out this blog.

After you have added your contact selector to the form, it will most likely look something like this:

Your data source will look similar to this

Note: Check to make sure your contact selector is working correctly before continuing with this blog.

As this is an expense claim, I only want the user to be able to enter one name into the contact selector. If you play around with the control, you'll find it's not as simple as just adding validation directly to the contact selector. To do this we need to add a couple extra fields to the form's data source.

Firstly, add 2 new fields to your data source:

'EmployeeNameCount' - This field is going to record the number of names that have been entered in the contact selector.
'EmployeeName' – This field will perform the validation check.

To add a new field, click on the "myFields" group in your datasource

Then click on 'Add new Field or Group'

Enter a name for your field and then click on Ok when you are done

After you have finished adding both fields, your data source should look similar to this:

Next we need to perform a count on the 'Person' repeating group and record this number in the 'EmployeeNameCount' field.

Double click on the 'EmployeeNameCount' field to open the field's properties

Click on the 'fx' button to insert a function

Insert a count function and point to the 'Person' repeating group in your data source, then click on ok. Your function should look like this:

Click on Ok to save the changes you have made to the 'EmployeeNameCount' field
At this point you might like to test that the EmployeeNameCount field is doing what it's supposed to do. To test, drag the 'EmployeeNameCount' field onto the form canvas.

Preview your form and then enter a couple of names into the contact selector. You should notice that the number in the EmployeeNameCount field corresponds with the number of names entered in the contact selector.

You can now delete the 'EmployeeNameCount' field from the form canvas (but leave the field in the form's data source)
Now we have a field counting the number of names entered in the Contact Selector, it is easy to set up validation to stop the user from entering more than one name. I prefer to set the validation check on the 'EmployeeName' field that we created at the start of this blog versus on the contact selector field itself. There is a good reason for this which I will explain later. But firstly, let's set up the validation rule.

Double click on the 'EmployeeName' field in the data source to open the field's properties.

Click on the validation tab and then click 'Add'

Set the condition "EmployeeNameCount is greater than 1"

In the 'Screen Tip' field enter "Only 1 employee name is allowed. Please remove excess names."

Your validation condition should look like this:

Click on Ok to save the validation and then Ok again to save the changes to the field's properties.
Publish your form, enter 2 names into the Contact Selector and then try to submit.

If you are using a browser enabled form, the validation error message you get should look similar to this:

Earlier on in this blog I said I prefer to put the validation on the 'EmployeeName' field rather than the Contact Selector itself. My reasoning behind this relates to the error message above. Notice that it includes the name of the field that holds the error. 'Employee Name' makes it easy for the user to identify the field with the error. If you place the validation condition on one of the Contact Selector fields such as 'DisplayName' it is not very intuitive.
Another thing that you can do to notify your users of the validation error is to include an error warning next to the contact selector on the form canvas.

On your form canvas, insert a section and in the section enter "* Only 1 employee name is allowed. Please remove excess names."

You might like to highlight the text in red and make it italics so it stands out.

Double click on the section you added to open the group properties

Click on the Display tab and then click 'Conditional Formatting'

Click on 'Add'

Set the condition "EmployeeNameCount is less than or equal to 1"

Tick the 'hide this control' checkbox

The condition should look like this:

Click on Ok 3 times to save the changes

Publish your form, enter 2 or more names into the Contact Selector.

Notice that when you enter more than 1 name the error message is displayed, making it easy for a user to identify the cause of the validation error.

If your form is client based (vs Browser enabled) then it is essential that you put this extra error warning on the form canvas. Validation errors in a client based form do not point the user to the field that is causing the error making it kind of confusing for someone when they are filling out the form.

That's it - you've finished. This method can be used to achieve other things as well. Say you wanted to enforce the user to input at least 2 names into the contact selector…. As long as you have the 'EmployeeNameCount' field, all it involves is setting up the correct validation conditions. Get creative and see what you can come up with.

Upcoming posts:

Make the contact selector mandatory
Use the contact selector to obtain other user details such as department, office and manager from the Profile Database
Validate the name entered in the contact selector

Posted at 4:48 PM by Alana Helbig | Category: InfoPath 2007 | Permalink | Email this Post | Comments (10)

5/07/2009

Content Types and Templates – Things I wish someone had told me

Ever since my light bulb () moment with content types, I've spent a fair amount of time working out the best way to set the little guys up. Something that I've stumbled across again and again is the (negative) effect that templates can sometimes have on content types. Below I've listed some things that I wish I had known when I first starting creating content types.....

Firstly, for those of you that may be new to content types.......

A template can very easily be applied to a content type by clicking on "Advanced Settings" in the settings for the content type

Once the template has been applied, when a user selects the content type from the 'new' menu in a library the relevant template will open.

Alternatively, if you do not apply a template, then a blank document will open (the type of document that opens will vary depending on the settings for a particular library).

Tip 1: Template Format

The term 'template' can be misleading. Often SharePoint site owners mistakenly think that the template applied to a content type should be in an office template format (i.e. .dotx or .dot). However I have found that using an office template document stops the document information panel from opening properly when a user selects the content type from the new menu in a library. Therefore, when preparing your templates for use with content types it's worth saving them in a standard office document format such as .doc or .docx.

Tip 2: Legacy Properties

Quite often template owners will copy someone else's document (i.e. using the 'Save As') and use the copy to create a template. This is very common – why not? It saves time right? There is absolutely nothing wrong with doing this as long as when preparing the template for use with content types the document is checked for legacy properties. You may like to spend some time reading my post about The Importance of Document Properties which outlines the effect legacy properties have on search results in SharePoint.

If we have a document with values in the document properties, just like the screen shot below

And we use this document as a template for our content type without first removing the properties, then whenever a user selects the content type from the 'new' menu, these properties open with the template. If the user doesn't check the properties (and often they don't), then the metadata for this type of content is incorrect and this starts to play havoc with your search results.

A very simple step to ensure that your template is free from legacy properties is to inspect the document for hidden metadata and other information. To inspect an office document:

Open the template and click on the office button in the top right hand corner of the screen
Select "Prepare" → " Inspect Document"
Click on "Inspect"
If document Properties are found, select to "remove all"
Your document should now be free of any properties which may affect the content type

Tip 3: Legacy Content Type IDs

Something I certainly wasn't aware of when I first started using content types is that whenever a document is created / uploaded into SharePoint and a content type is selected, a 'Content Type ID' is inserted into the advanced properties of that document. Just so you know I'm not lying, try adding a new document into a SharePoint library and apply a content type. Then:

Click on the Office Button in the top left hand of the screen
Select Prepare → Properties

In the document information panel (DIP) at the top of the document, open Advanced Properties
Select the Custom tab and you'll notice that the Content Type ID is listed here

This ID stays with the document. Even if you download the document onto your desktop, the ID comes with it. This is not normally a problem; in fact it is quite useful - if we move documents from one location to another, the ID helps the document to remember what type of content it is. The only time this is a problem is if we try to use a document that has a content type ID as a template.

If we happen to do this (as I have done) then the content type starts to get very confused and starts to misbehave at the library level (i.e. it affects your users). Once again, it's very simple to ensure that this type of thing doesn't happen. Just run the document inspection tool (see tip 2) on your proposed template and remove any hidden metadata before applying it to the content type.

Tip 4: Be careful when using the 'Enter the URL of an existing document template' option

You might have noticed in the advanced settings of a content type, that there is an option to enter the URL of an existing document template.

I was really excited about this idea when I first saw it. I thought it meant I could store the document template in a library in the template owner's site. They could then freely update the template whenever they like and this would automatically update all libraries and lists using that content type. It meant I wouldn't have to give the template owner permission to modify content types, hence giving them permission to other settings that I probably didn't want them to touch.

Unfortunately, I think this idea still needs a little work..... let me show you what I mean

The Scenario

I have created a content type called 'My Company Report' and I have applied metadata columns of:

Date Written
Department
Brief Description

The next step is to create a library somewhere in SharePoint where you will store all your templates that will be applied to the content types. In this example, I have created the library in the top level site and called it 'Templates'.

I then apply the 'My Company Report' content type to that library

Now I upload the 'My Company Report' template into the library and I tag it with the content type 'My Company Report'. I leave the remaining fields empty.

I then copy the URL of the My Company Report template

Back in the advanced settings for 'My Company Report' content type I paste the URL of the template into the relevant field and say ok.

So far so good…..

Now my content type, with relevant metadata and template is ready to be pushed out through my site collection. I go to a library somewhere in my site collection (in this example I'm using a library called 'reports) and apply the My Company Report content type to the library

Now it looks like it's ready to use…. So go ahead and click to create a new My Company Report… Looks like everything worked perfectly hey? DIP opened, the document saved into the correct library, there were no errors…. In fact, yes, this method does work perfectly… until, we add in mandatory list columns.

List Columns

Now, in this particular reports library, my users would like to also capture the 'Project Name' against each report when saved. They only want to do it in this library and not for any other reports saved elsewhere in the site collection. So it makes sense that we would just apply the list column to this particular library and not to the content type itself.

So I go into the library and apply a new column called 'project name' – make the column mandatory. Everything seems ok….

Now I create another new My Company Report… and looks as though everything worked ok again… however if you pay particular attention to the document information panel you'll notice that there is something missing…

The 'Project Name' field you created is not there.

Go ahead and try to save your document - you'll probably get a similar error message like the one below

So why does this happen? When a user creates a new document from the new menu in the 'Reports' library, the settings from the template (the one saved in your central 'templates' library) overrides the settings on the 'reports' library. Then when the user saves the document, the settings from the Report library are applied and this is what causes errors, things not to appear on the DIP when they should etc etc.

This blog is long enough so I'm not going to go into any more detail but if you have a play I'm sure you'll discover some other short comings with this method.

So overall, when you are preparing your templates for use with content types, make sure you check these few things:

Use the correct template format (i.e. .doc or docx)
Scan your template for any legacy properties
Be careful when using the 'Enter the URL of an existing document template' option

Good luck!!

Posted at 10:25 AM by Alana Helbig | Category: Content Types | Permalink | Email this Post | Comments (0)

KPI List not available

I had a question from a client the other day regarding creating a KPI list. The user was a site collection administrator and had been creating various KPI lists in a number of the sub sites. However, in one particular site, the option to create a KPI list was not available.

KPIs are part of the SharePoint Enterprise features therefore the enterprise feature needs to be activated in order for this list to be available. So, to make the list available, go to Site Settings > Site Features and activate the feature

The KPI list then becomes available.

Posted at 10:11 AM by Alana Helbig | Category: SharePoint - General | Permalink | Email this Post | Comments (0)

13/03/2009

White Paper - Plan Content Types in SharePoint

One of the most common problems in any organisation today relates to the management of large amounts of information and documentation. Information workers find it difficult and time consuming to find what they are looking for, content owners struggle to keep content up to date, version control is a nightmare and processes are inefficient.

I have recently finished writing a white paper that introduces the concept of content types in SharePoint and explains why an organisation may choose content types to assist with information and process management. The paper outlines key factors to consider when planning for content types, the aim being to provide the reader with a logical approach to planning content types in the SharePoint environment. Finally, the paper addresses three of the most commonly used content type settings – metadata, templates and workflow – and details how each of these settings can assist an organisation with the management of information and information-related processes.

I wrote this paper because too many times we see companies go down the path of migrating all their documents into SharePoint without using content types, only to have them come back later and say 'we can't find anything'. Hopefully, after reading this white paper, you will understand why I keep harping on about how important content types are.

Happy reading!!

Click here to open the white paper

Posted at 8:24 AM by Alana Helbig | Category: Content Types | Permalink | Email this Post | Comments (1)

4/02/2009

Show tasks due in this working week or in this month

How do I create a view of tasks that are due in this working week or in the next working week? For a quick fix we could use formulas such as [Today]+7 but this is just adding 7 days from today's date and therefore doesn't really give us what we are after. So give this a go instead….

Tip: SharePoint Calculated fields take the same formulas as those used in excel… I test my formulas in excel first before adding them into SharePoint. This can be much faster plus excel is a little nicer and will often tell you how to fix any errors in your formulas.

Show tasks due this week

Work out the week start date and the week end date for the week in which the due date falls.

Create a calculated column in your task list called 'Week Start' and use the formula:

=[Due Date]-(WEEKDAY([Due Date],2)-1)
Create another calculated column in your task list called 'Week End' and use the formula:

=[Due Date]+(7-WEEKDAY([Due Date],2))
Your task list will look something like this… - check to make sure that your dates are correct

Create a new view and filter

Create your new view and give it a name such as 'due this week'
Filter the view as follows…..

Voila it's that easy! You now have a view that shows you all tasks due in the current working week!!

Read this blog if you would like to understand the weekday formula in more detail

Show tasks due next week

Once you have worked out the week start and week end dates in which the due date fall, it's very easy to work out tasks that are due next week, last week so on…..

Work out the previous week's start date and the previous week's end date of the due date

Create a calculated column in your task list called 'Previous Week Start' and use the 'week start' column you created above to calculate by subtracting 7:

=[Week Start]-7
Create a calculated column in your task list called 'Previous Week End' and use the 'week start' column you created above to calculate by subtracting 1:

=[Week Start]-1
Your task list will look something like this… - check to make sure that your dates are correct

Create a new view and filter

Create your new view and give it a name such as 'due next week'
Filter the view as follows…..

You now have a view that shows you all tasks due in the next working week

Show tasks due this month

What about if we want to show tasks that are due this month and next month?

Work out the month start date and the month end date for the month in which the due date falls.

Create a calculated column in your task list called 'Month Start' and use the formula:

=DATE(YEAR([Due Date]),MONTH(Due Date),1)
Create another calculated column in your task list called 'Month End' and use the formula:

=DATE(YEAR([Due Date]),MONTH([Due Date])+1,1)-1
Your task list will look something like this… - check to make sure that your dates are correct

Create a new view and filter

Create your new view and give it a name such as 'due this month'
Filter the view as follows…..

Show tasks due next month

Work out last month's start date and last month's end date of the due date

Create a calculated column in your task list called 'Last Month Start' and use the formula:

=DATE(YEAR([Due Date]),MONTH([Due Date])-1,1)
Create another calculated column in your task list called 'Last Month End'
- If you have created the 'month start' date column in the steps above you can use the formula:
  
  =[Month Start]-1
- If you haven't followed the steps above, you can use the formula:
  
  =DATE(YEAR([Due Date]),MONTH([Due Date]),1)-1
Your task list will look something like this… - check to make sure that your dates are correct

Create a new view and filter

Create your new view and give it a name such as 'due next month'
Filter the view as follows…..

Find out more about the date formula

You can also do this with calendars and other lists.....

One last thing – you might want to hide the calculated columns so that users don't see these fields when they are viewing existing task properties….

Open the settings page of the list and click on 'Advance Settings'
Allow management of content types and say ok
Back on the settings page of the list click on the 'Task' content type
Click on the first calculated column listed
Mark the column as hidden and say ok
Do this for the remaining columns

Posted at 7:20 PM by Alana Helbig | Category: SharePoint - General | Permalink | Email this Post | Comments (0)

3/02/2009

The Importance of Document Properties

Before SharePoint arrived document properties were something that not a lot of people used. In fact it is surprising to think that some people don't even know they exist!! However, now that SharePoint is here, we need to train and inform our SharePoint users on just how important document properties are.

Often when I start talking about document properties to users I get puzzled faces looking back at me. So I've written this blog in an attempt to try to explain what document properties are, how to use them and where to find them. I've also included some best practices when mixing document properties with SharePoint.

What are Document Properties?

Document properties (or metadata if you want to be fancy) are named values that provide information about a particular document.

A person may 'tag' their document with properties if they want to:

Record a history about the document (such as the author, date created, last modified, version)
Record comments about the document
Categorise documents
Use these properties to later search for documents (this is particularly the case in SharePoint)

Document properties can be categorised into 2 types:

Standard; and
Server

Standard Document Properties

Standard document properties are the default properties that come with all office documents. These include:

Title
Author
Subject
Keywords
Category
Status
Comments

You can access the standard document properties of a document by either:

Right clicking on the document and selecting Properties

Or for office documents you can:

Open the document
Click on the Office Button in the top left hand of the screen
Select Prepare → Properties
Notice the document information panel (DIP) appears at the top of the document

Server Document Properties

Server document properties are custom properties that are defined in SharePoint. These types of properties help SharePoint file the document correctly, assist with filtering and grouping of views and also help you and others to later find the document easily when using the search and filtering tools. Therefore, it is important that these properties are filled out correctly.

The types of properties displayed will vary between different libraries and types of documents. However, there are certain server document properties that are always present. These properties are:

Name
Title (corresponds with the standard document property title field)
Created By and Created Date (generated by SharePoint and cannot be modified)
Modified By and Modified Date (generated by SharePoint and cannot be modified)

You can access the server document properties of a document in SharePoint by one of the following methods:

For office documents:

Open the document in SharePoint
Click on the Office Button in the top left hand of the screen
Select Prepare → Properties
Notice the document information panel that appears at the top of the document
In the document information panel, next to the Information Icon ensure that Server Document Properties is selected

For office documents and other non-office documents:

Find the document in SharePoint. Hover over the name of the document and notice that an orange box appears. Click on the drop down arrow.
Select View Properties to view the server document properties
or select Edit Properties to edit the server document properties

Mixing Document Properties with SharePoint

It is good practise to always check document properties even if we are not saving the document into SharePoint. The thing we have to keep in mind is that eventually our document may end up on SharePoint or could be PDF and then uploaded into SharePoint. If the properties are incorrect when saving the document, then this will eventually flow through into SharePoint and effect search results. Not all document properties have to be filled in but there are some key things that you should pay attention to when saving your documents:

Check the Title field

The title of your document is what is returned in the search results heading in SharePoint. A common mistake is to think that the name of the document appears in the search results. This is not the case.

A perfect example of this is the Document Properties screen shot below. Notice that the title of the document is 'The Importance of Document Properties' but the actual document name is 'Document Properties'

This can be very deceiving if the title field has not been filled in correctly or if it contains legacy information not applicable to the document. I have seen many users copy a document (i.e. by using the 'Save As' function) and then upload this new document into SharePoint without checking the Title field. As a result the document often ends up with a title that is just not relevant to that document. Next time someone searches for the document, search returns the document in the results, however the title is not what the user expects it to be. This is when users start to complain that search is not working.

To ensure this doesn't happen, we need to train our users to always check the title field and either:

Enter a title that is relevant; OR
Ensure the title field is blank – by leaving the title field blank, the search heading defaults to the document name

Check the Author field

Similarly to the title field, if you copy a document that someone else has authored (i.e. by using the 'Save As' function) your name will not appear in the Author field. Always check the author field to make sure it is correct

Always fill in mandatory server document properties

When saving a document to SharePoint, you should always fill in the mandatory server properties. Mandatory server properties are marked with a red *. These properties have been made mandatory for a reason –they may assist with search results or they may have an effect on the grouping or filtering of that particular library.

If you do not fill in the mandatory fields, it is likely that your document will remain checked out. A checked out document has a little green arrow next to the file type to indicate it is checked out.

If a document is checked out by you, others will either not be able to see it or will not be able to view the changes you have made until you check the document back in.

Posted at 7:45 PM by Alana Helbig | Category: SharePoint - General | Permalink | Email this Post | Comments (1)

RSS Feed

1 - 10