New Deliverable Type - General Correspondence

A general correspondence is a new type of package that is intended for managing various official project communications. General correspondences are currently only a feature of the portal.

Each project contains a general correspondence template, which the administrator can use to create as many general correspondence package types as your organization needs. For example, you might create a general correspondence package type named "Meeting Notes", and another named "Contractual Documents". A default, preconfigured general correspondence package type, named "General Correspondence", is also available which you can use as is or customize as needed.

To add a new general correspondence package type to your project, go to the Attributes tab of the portal settings and click the + (plus) symbol to the right of the General Correspondence attributes tab.

This lets you create a new package type, named whatever you like, based on the general correspondence template.

On the attributes tab for your new package type, you can configure any custom attributes as needed.

Once a general correspondence package type exists in your project, portal users can create a new package of that type by clicking the New menu and selecting the package type from the menu (for example, New > New General Correspondence or New > New Meeting Notes).

Like a transmittal or an RFI, a general correspondence has a subject, details, recipients, and due dates for acknowledging and responding.

After you issue a general correspondence, the recipients can acknowledge and respond as required. If a recipient is not required to respond (their Resp permission is turned off ("N/A") in the general correspondence) they can still send an optional response. As the author of the general correspondence, you can review the recipients' responses.

You can also reply to a recipient's response. When you reply, a new general correspondence is created for the reply.

See:

Sending General Correspondences

Managing Incoming General Correspondences

Configuring the Attribute List for General Correspondences

Marking One Person as the 'Consolidator' of Additional Responses for Submittals

In Update 4.1 this feature was added for RFIs. Now this feature has been extended to submittals.

When requesting additional reviewers to respond to a submittal you received, you can now mark one of those reviewers as the Consolidator (meaning the consolidator of additional responses), so that the other additional reviewers will send their responses to the consolidator, who will then combine those additional responses into a single response to send back to you (the original submittal recipient).

If you select multiple additional reviewers and do not mark one as the consolidator, then all reviewers will have the same response due date. If you mark one of the additional reviewers as the consolidator, then the consolidator's due date will be 2 days later than the other additional reviewers' due date (giving the consolidator time to combine the other responses into a single response).

If you select multiple additional reviewers and do not mark one as the consolidator, then your name will appear in the Respond to field for all of the responders on the Additional reviewers tab. If you marked one of the additional reviewers as the consolidator, then your name (the name of the original submittal recipient) will appear in the Respond to field for the consolidator, and the consolidator's name will appear in the Respond to field for the other additional reviewers.

See: To Request Submittal Responses from Additional Reviewers

Submittal Recipients Who Are Not Required to Respond Can Now Be Selected as Additional Reviewers

Previously, when selecting additional reviewers for submittals, you could only select internal project participants who did not receive the submittal. Starting with this release, you can also select internal project participants who received the submittal but who were not required to respond (their Resp permission is turned off ("N/A") in the submittal).

See: To Request Submittal Responses from Additional Reviewers

Submittal Recipients Who Are Not Required to Respond or Acknowledge Can Now Be Selected as Delegate Responders

Previously, when selecting delegate responders for submittals, you could only select internal project participants who did not receive the submittal. Starting with this release, you can also select internal project participants who received the submittal but have no actions required of them (their Ack and Resp permissions are turned off ("N/A") in the submittal). Also, submittal recipients who are only required to acknowledge the submittal can now select a delegate responder who will acknowledge the submittal on their behalf.

See: To Select an Internal Participant (delegate responder) to Respond to a Submittal on Your Behalf

Adding Additional Reviewers to a Transmittal Draft Through the Document Distribution Matrix

A submittal recipient who is required to respond can send a request to one or more internal participants (additional reviewers) to also respond to selected documents in the submittal.

In the document distribution matrix, you can now configure a distribution rule so that one or more recipients who are required to respond are automatically added to the transmittal draft with their additional reviewers already assigned.

When the distribution rule is applied to the transmittal draft, a note is added in the Details column (on the Audit Trail tab in ProjectWise Explorer, or on the View History page in the portal), listing which additional reviewers were selected to send responses to which recipient. When the transmittal is finally issued, either the responder, or any of their pre-assigned additional reviewers, can acknowledge the submittal. This allows the additional reviewers to begin reviewing and responding to the documents in the submittal without having to wait for their responder to acknowledge it.

In a related change, if a recipient is a participant in more than one project, you can now specify to which project that recipient will receive the transmittal package by adding the project number (inside parentheses) after the recipient's email address. For example: company_user@company.com (Project Number)

See: Configuring Distribution Rules for Transmittals

Bentley IMS Admins Are Now Automatically Added to the Project When They Enter the ProjectWise Deliverables Management Portal

Any Bentley IMS administrator (Account Admin, Co-Administrator, or CONNECT Service Admin) who enters the ProjectWise Deliverables Management portal of their organization's project is now automatically added an administrator of that project (internal participant with the Admin permission). This provides a way for other members from your organization to take over as administrator in the event that the current administrator happens to be away, or has left the organization.

New Acknowledgement 'Due Date' Settings for Transmittals and RFIs

In Update 4.1, the ability to set a default due date for transmittal and RFI responses was added to the portal settings, on the Scheduling tab. Starting with this release, now you can also set a default due date for transmittal and RFI acknowledgement.

The default due date for acknowledgements is 2 days after the item is issued, and the default due date for responses is 14 days after the item is issued. The user configuring the transmittal or RFI can either keep the default due dates or change them as needed before issuing the transmittal or RFI. Currently these default due date settings do not apply to general correspondences.

See: Configuring Default 'Due Date' Settings for Acknowledgements and Responses

Single Package ID for Outgoing and Incoming Versions of the Same Package

In new projects, for all package types, the incoming version of a package will have the same ID as the outgoing version of the package. This means that in the portal settings (Settings > Identification > Numbering) there is now only one numbering rule to configure for transmittals, and only one numbering rule to configure for RFIs.

Package ID numbering rules in new projects:

In existing projects, for transmittals and RFIs, outgoing and incoming versions of the same package will continue to have separate package IDs. This means that in the portal settings you can continue to configure separate numbering rules for the outgoing and incoming versions of transmittals and RFIs.

Package ID numbering rules in existing projects:

See: Numbering Rules for Generating Package IDs