answering this from a functionality standpoint, we like calculated fields and use them in forms to achieve a number of goals. So here are some simple things we do. * we carry information from larger objects to smaller objects (e.g. portfolio information all the way into issues through the project custom form), or project custom form information to the task for the users who needed a specific subset of information but don't want to wade through the whole form. These are time savers, they save us from wandering all over the place collecting the context we need to do our jobs. But they also have some reporting wins -- we can group by fields that aren't usually available to us. e.g. we group a lot of reports using the user's Home Team or Home Group names, and it's simpler to put a custom field on the user that carries this information. * we pass information through when objects are converted (when tasks or issues are converted to projects) -- e.g. if the project needed the originating issue's entry date for a calculation, we would pass the entry date to a calculated field in the issue custom form, and reference the same field in the project custom form. (issue's calculated field says Entry Date / project's calculated field says {the name of the issue calculated field}) * Reporting functionality: we compare apples and oranges. Team 1 does work for Divisions 1, 2, 3. Team 2 does work for Divisions 4, 5, 6. We can categorize their work by having them select those divisions in their dropdown (team 1 PMs select from Division1 field with dropdown for 1, 2, 3. Team 2 PMs select from Division2 field with dropdown for 4, 5, 6. The calculated field on both their custom forms will reference either Division1 or Division2, and the resulting bar chart will show team 1 and 2 work grouped by Division Calculated Field: 1, 2, 3, 4, 5, 6) I know this looks silly, because why not give them the same 6 divisions and make them pick from the same field. But we have one team who has spawned 32 queue topics each with a different list of available Brands. It's nice not to have to pick from 100 brands if you know this particular request only is available for 7. And now they have a way to report based on the Brand without it being a pain in the neck. * Reporting functionality: we can reduce different apples to just a general apple. Taking the above example, we could say "if it's Division 1 and 2, we want it to be called Red. If it's Division 3 or 4, we want it to be called Green. And if it's Division 5 or 6, called it Blue.". This will give us a chart with 3 bars: Red, Green, and Blue. Or here's another example: we have a team that thinks that they're only late if the actual completion date is greater than the planned completion date by over a day. So figure out the difference between your two dates (I use weekdaydiff because we have a fairly standard corporate schedule) to figure out the difference and then a second calculation calls the first field on time only if it's within the parameter. e.g. IF(Firstfield<=1, "On Time", "Late"). Now you can pull a chart comparing on time to late tasks. By the way, we of course don't really compare actual to planned completion dates--that's just a more generic example that uses fields most users are familiar with. We've ended up doing this same calculation comparing actual completion date to baseline planned completion date for all our milestone tasks--as a way to eyeball which milestones are late by over a day by using a date that doesn't have to change in order to keep the project timeline on track. -skye
