Recently we've been working on an employment/mentoring site with Drupal 7 with a quite complex business workflow. The site features a large number of custom processes that mirror the client's off-line operations.
At many points of the process there are documents completed that build on the workflow. For a number of reasons we've chosen to implement these documents as nodes rather than webforms - including access controls and other built-in node behaviours.
The technical design issue we encountered was that many of the documents are variations on a theme depending on their position in the whole process. Rather than slow down the site performance by adding additional content types, we decided it would be best to merge as many of the largely similar content types into a single form and then show/hide fields based on the process.
Enter the Field Permissions module. The interface for the module has been cut down from the Drupal 6 version (which shipped as a sub-module of CCK) and you can now define what permissions you need to make available on a per-field basis. This is a huge improvement on how it worked in Drupal 6 - with Drupal 6 once you enabled the module access to all fields were then governed by field permissions. With the Drupal 7 version - you get to nominate which fields have their access control governed by field permissions. You can even nominate which permissions you need from - edit any, edit own, view any, view own, delete any and delete own. This means the permissions form is far less cluttered and the default behaviours are far more friendly.
So in this case - we took three largely similar forms and combined them into one. Then we used roles to govern whether the fields were visible. As the user progresses through the whole business process, we'll use Rules to grant them the permission to see the fields as needed.