from memory, I'm not satisfied with the way reports are automatically delivered. I think at the time, I was unhappy that empty reports could be sent out (if a report has nothing on it, it should not be sent). If this is still true, I would rather work toward an option where the client is coached to log in and review their dashboard for all status. Depending on what your workflow is, it almost feels as though there are 2 reports you need to create: one is regarding the status of the request they submitted (here's a list of my submitted requests and here's the status they are in--if a project is created from that request then here's the name of the project). The second report would be "here's a list of all the projects and where they are at" (milestones and parent task information I guess?). Some things to note: * some workflows opt to put milestone tasks at the parent task level. If this works for you as well, then you might not have to report on milestones and/or parent tasks if they are one and the same. * it's common for people opt to put the requestor's name in under Project Sponsor and this allows you to pull project reports based on that. For that second report, a project report with Jason's suggestion for milestones is nice. But if it's too fiddly, OR doesn't give enough information, there's absolutely no harm in making a task report that groups by project and is ordered by task number. It's really just a matter of preference. (In my experience, the executive levels usually would prefer to look at pictorials (pie charts, bar graphs, color) to get that overall feel and don't need to drill down that deeply. I think Jason provided some code for "active milestone" that speaks to this scenario (rather than showing them all the milestones, only show them the active one). -skye
