Poll: Favorite Calculated Field(s)?

This is a fun thread to find on a Monday morning! Ours are pretty simple, a few of mine is: A field that calculates what the 60 day date is before an item expires 'Original' requestor field to know who submitted the request on the project form A 'last note' field that has the last comment + person who posted it + date it was posted in one field. Document piece code - our team can struggle to know what code should be on a final piece of collateral. So a calculated field that shows Project#-(custom field)-Object # for every document is really helpful. A summary field that captures multiple field choices in one. ex. Branding_PSG, Branding_RPS, Branding_FUT, Branding_Corp - are all displayed in a Branding_All calculated field. I love the org chart one - just wish we could see it visually as a report!

Hi Christina, would you mind showing how your "Last Note" field calculates please? This sounds like the exact thing a number of our staff have requested to be added on their dashboard, but I haven't got it working reliably yet. Would really appreciate you explaining how it works. Does it also allow a user to make an update on the task from that calculated field within a dashboard? (similar to how you can make an update directly on a task in My Work, but in this case doing so without having to leave the task showing on their dashboard) Many thanks Mike Michael Hagger

@Michael Hagger , I believe Christina is referring to the "Latest Update" example on the WFPro text mode library. My favorite calculated field is "https://wf-pro.com/textmode/text-mode-views/#active-tab-links" activeTab , which also happens to be in the library. While this example shows how a hyperlink is rendered out in the view, my favorite thing to do is to calculate a url on the object's custom form. From there, you can build some really nice views, such as this project view with clickable links to get into the sub-areas of the project (custom forms, updates, issues, etc.). These enhancements reduce the number of clicks required to get places, which is why activeTab is my favorite.

Thank you, Narayan, for sharing. I'm a novice at text mode so this is very helpful! If anyone else has code they can share, I would appreciate it. Dr. Rochelle L. Webb, CSM Sr. Project Manager, Project Management Office MHMR Tarrant County Ft. Worth, Texas 817-569-4146

We have a task custom form where we fill in print specs, then the task has an approval that goes to the requester to approve their print costs. What we didn't know until recently was that they need the unit cost to send along to the warehouse. So we added a simple calculated field based on the quantity and total cost - they get the unit cost they need handed to them and our print coordinator doesn't have to do any extra work or fill in an extra field.

Thank you for sharing Ashley! It was easy to use and worked perfectly. Dr. Rochelle L. Webb, CSM Sr. Project Manager, Project Management Office MHMR Tarrant County Ft. Worth, Texas 817-569-4146

Thanks for sharing, everyone! Would love to see what else people have up their sleeves. _______________________________ Ashley Adam Amazon IT Services One Door System Administrator

Here's the text mode we use for last note/update, we decided to shorten the text as sometimes the note can get very long and will stretch out the report Last note with shortened text Change column numbers based on location (5 cols total) column.11.displayname=Last Update column.11.linkedname=lastNote column.11.namekey=view.relatedcolumn column.11.namekeyargkey.0=lastNote column.11.namekeyargkey.1=noteText column.11.querysort=lastNote:noteText column.11.sharecol=true column.11.textmode=true column.11.valueexpression=IF(LEN({lastNote}.{noteText})>350, CONCAT(SUBSTR({lastNote}.{noteText},0,349),"...(open for more) -- "), IF(LEN({lastNote}.{noteText})>0, CONCAT({lastNote}.{noteText}," -- "))) column.11.valueformat=HTML column.12.sharecol=true column.12.textmode=true column.12.value= column.12.valueformat=HTML column.12.width=1 column.13.displayname=Last Update By column.13.linkedname=lastNote column.13.namekey=view.relatedcolumn column.13.namekeyargkey.0=lastNote column.13.namekeyargkey.1=owner:name column.13.querysort=lastNote:owner:name column.13.sharecol=true column.13.textmode=true column.13.valuefield=lastNote:owner:name column.13.valueformat=HTML column.14.sharecol=true column.14.textmode=true column.14.value= |  column.14.valueformat=HTML column.14.width=1 column.15.displayname=Last Update Date column.15.linkedname=lastNote column.15.namekey=view.relatedcolumn column.15.namekeyargkey.0=lastNote column.15.namekeyargkey.1=entryDate column.15.querysort=lastNote:entryDate column.15.textmode=true column.15.valuefield=lastNote:entryDate column.15.valueformat=longAtDate Monique Evans Stanley Black & Decker, Inc.

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