Upgrade 26.1.0 (Rev 260916) - Resolutions

Contract Insight Resolutions

For clients who received an early upgrade to Version 26.1.0 (Rev 260821), below are all of the resolutions applied in Version 26.1.0 Rev 260916.

Core System: Contract Insight

System Administrator Setting Could Be Turned On for an Account on Any License Level

Reference #: 260916.100.0500

On an employee record the Sys Admin setting could be turned on for any account whatever its license level, and that single setting is the whole of what makes someone a system administrator, so one save could give a read only account full administrative rights. This has been resolved so the setting is read only unless the person editing holds Manage permission on employees and the account being edited is on the administrator license level, which is the rule that was always intended. Upgrading does not alter existing data, so an account already carrying the setting on a lower license level keeps it until an administrator corrects it.

How will this affect users? End users are not affected as only System Administrators have access to this setting. Administrators should review which accounts carry the Sys Admin setting after upgrading.

Other People's Tasks Appearing in My Tasks Through Delegation

Reference #: 260916.100.0501

In version 22.7 the contract task list widened its employee filter with a delegation rule that actually asked whether an employee was their own delegate, so a small number of employees' tasks appeared in every other user's task list while the people who genuinely were somebody's delegate never received the tasks delegated to them. This has been resolved so you see your own tasks plus the tasks of anyone who has named you as their delegate; the same correction applies to My Tasks and to the tasks card on the Home page.

How will this affect users? Every user with a task list is affected. On upgrade, true delegates gain the rows they should always have had, and users lose rows that were never theirs.

Record Save Refused for a Duplicate Value When Nothing Was Duplicated

Reference #: 260916.100.0502

Saving a record could be refused with a uniqueness message although nothing was duplicated. Empty values were compared against each other, so every record with a unique field left blank collided with every other, and a single pair of records that already shared a value, created before the field was marked unique or loaded by an import, could never be saved again on any field. This has been resolved so blank values are not compared, and on an existing record a unique field is checked only when its value has actually changed. Creating a genuine duplicate is still refused, the message now names the record type the rule belongs to and how many records already use the value, and a refused save scrolls its reason into view rather than leaving it above the fold on a long form.

How will this affect users? Anyone editing records on a system with unique fields configured will be able to save records that previously could not be saved at all.

Clearing a Required Field Lost Every Other Change on the Form

Reference #: 260916.100.0503

Clearing a field on a record whose underlying column cannot be empty failed the entire save with a database error, so every other change on the form was lost; editing and saving a task was a common way to meet it. This has been resolved so clearing such a field stores the column's own default value and the rest of the save succeeds. Where the column cannot be empty and has no default, that one field keeps its existing value and everything else still saves.

How will this affect users? Everyone editing records benefits, most visibly on tasks and other record types with many mandatory fields.

Record Timeline and Audit History Took Many Seconds to Open

Reference #: 260916.100.0504

On systems with a long activity log, opening a record's Timeline panel or its Audit History screen took many seconds. This has been resolved so both read the record's trail directly, supported by an index that installs with the upgrade. Measured on a full size database, one carrying about eighty million history entries, the timeline read went from about 8.8 seconds to 25 milliseconds and Audit History from about 9.5 seconds to 0.16 seconds, returning exactly the same entries in the same order. The timeline no longer reads whole stored email bodies in order to draw a subject line, and Audit History loads the most recent five thousand entries with a banner saying so, while exports still contain every entry.

How will this affect users? Anyone opening the Timeline or Audit History on a record, especially long lived records on large systems, gets an immediate answer.

Contract Tasks List Timed Out Before Anything Appeared

Reference #: 260916.100.0505

Opening the Contract Tasks list on a large database could take around ninety four seconds and time out before the list appeared. This has been resolved with three supporting indexes that ship with the upgrade, so every environment receives them; measured on the same full size database, the list now returns in under four seconds.

How will this affect users? Anyone opening the Contract Tasks list, particularly on databases with millions of task rows.

A Person Named on a Record Disappeared After That Person Was Deactivated

Reference #: 260916.100.0506

Where a record named an employee who had since been deactivated, the field rendered blank and the next save committed that blank, quietly dropping the name from the record. This has been resolved so the person is shown under their own name and stays on the record unless somebody changes it. Fields that name a person now use a searchable picker that still draws its options from the field's own configured list, so client specific filtering such as one department or one license type is respected.

How will this affect users? Anyone editing records that name people, especially records naming staff who have since left the organization.

Records Created Automatically Were Not Linked Back to the Record They Came From

Reference #: 260916.100.0507

Accepting a request and letting an automatic flow create the contract produced the contract and wrote both history entries, but left the linked and associated requests list empty, with nothing on either record pointing at the other and the contract's own request reference blank. Converting a request by hand linked the two records; letting a flow do it did not, and the same applied to records created from purchase orders, solicitations and vendors. This has been resolved so a record created by a flow is linked back to the record that produced it and carries the originating reference. Records created before the upgrade are not linked retroactively.

How will this affect users? Anyone using record flows or automatic record creation from requests, purchase orders, solicitations or vendors.

Converting a Record Copied None of the Related Rows and Files It Was Configured to Copy

Reference #: 260916.100.0508

Where a conversion is configured to let a person choose which related rows and files to bring across, the screen that asks was never shown, so nothing was ever chosen and those pairings copied no rows and reported nothing. This has been resolved so a selection screen appears before the new record's form, listing the candidate rows and files with the awarded vendor filter applied. Pairings in this state included contract to contract files and notes, and solicitation to contract files. Two further faults in the same area are corrected: a related list's field mapping can no longer be read as a record level mapping and write a value onto the parent record, and on installations whose files are held in cloud storage a copied file is no longer created without its storage link.

How will this affect users? Anyone converting a record, for example a request to a contract, now receives the related rows and files they select instead of silently receiving none.

Bulk Enrollment Into Compliance Monitoring Registered No Monitors

Reference #: 260916.100.0509

Enrolling records into compliance monitoring in bulk from the Compliance Review screen reported success while nothing downstream happened, because the queue it filled had no process to drain it. This has been resolved so the scheduled risk comparison job refreshes comparison baselines on its recurring schedule and works through that queue. Three long standing traps are removed at the same time: a definition that fails a run is logged and left in place rather than switched off and deleted with nothing to say where it went, a missing batch size falls back to a sensible default instead of stalling the queue indefinitely, and a queued row for a tool other than the sanctions check is completed with a reason instead of permanently blocking the front of the queue.

How will this affect users? Anyone who enrolled records into compliance monitoring in bulk; those enrollments now take effect.

Links and Downloads Failed on Sites Installed Under a Sub-Folder

Reference #: 260916.100.0510

On sites installed under a folder rather than at the root of their web address, several links were built from the root of the site address and lost the folder. The open button on every sub-table row returned a page not found error, exports from sub-table and linked record lists did not download, saving a new employee left the browser on a page not found error although the employee was created correctly, and completing a multifactor challenge returned the user outside the application. This has been resolved so those links are built relative to the application and work wherever the site is installed. Sites installed at the root of their address were never affected.

How will this affect users? Every user on an installation that runs under a virtual directory or sub-folder, which is how most customers are hosted.

Opening a Second Browser Tab Signed You Out of the First

Reference #: 260916.100.0511

A second tab was treated as a new sign in, and that second sign in ended the first tab's session, so two tabs could take turns signing each other out. This has been resolved so signing in survives a new tab, a new window and a browser restart, still governed by the same setting that allows persistent sessions and the same session timeout. A tab left open from an earlier session no longer ends the session you are actually working in, a record with unsaved changes no longer blocks a forced sign out, and session length, sliding renewal and automatic sign out for inactivity are unchanged.

How will this affect users? Every user, particularly anyone who works with more than one Contract Insight tab open.

Permission Inheritance Granted Too Much on Top-Level Record Areas

Reference #: 260916.100.0512

When permissions were resolved, a record area with no parent was treated as though it had one, so the inheritance rules could grant more access than they should on top level areas. This has been resolved so an area with no parent inherits nothing.

How will this affect users? Permissions now resolve correctly on top level record areas. System Administrators should confirm that the access their security groups grant is what they expect after upgrading.

Checks That Ran on the Button Rather Than Where the Work Happens

Reference #: 260916.100.0513

Two access checks did not hold where they mattered. When a configured view restriction on files could not be evaluated, for example because a column it names had since been renamed, the file list quietly fell back to listing every file on the record and nothing was recorded, so nobody could find out; and the calendar export was checked on the button that starts it rather than at the point the file is produced, and because the download address is predictable a month of calendar alerts was reachable by anyone who was signed in. This has been resolved so a restriction that cannot be evaluated returns no files and records the failure, and the Export Calendar permission is checked when the file itself is produced. Opening a file was always checked separately, so what a broken restriction exposed was the list of file names rather than their contents.

How will this affect users? Users whose access to files is limited by security group conditions, and all clients, whose calendar exports are now limited to the people holding the export permission.

Denied File Types Could Still Be Uploaded From a Record's Files Tab

Reference #: 260916.100.0514

The list of file extensions an administrator has denied was not consulted everywhere a person can upload, including a record's Files tab. This has been resolved so the restriction is applied wherever a file is written, and it is named on the file as soon as it is chosen, alongside the too large and empty file messages, rather than after the upload has been attempted. Files produced by the system itself, such as a signed document returning from a signing provider, and attachments arriving by inbound email are deliberately not blocked.

How will this affect users? Administrators who restrict upload types, and anyone uploading files to a record.

Workflow Screens Opened Only for System Administrators

Reference #: 260916.100.0515

The workflows list, the workflow detail screen and the workflow diagram were restricted to system administrators, so employees holding View Workflows or Manage Workflows were locked out of the screens those permissions name. This has been resolved so the screens use the same workflow permissions version 22.7 used, and the same checks now sit behind every workflow save and delete so the rules cannot be bypassed.

How will this affect users? Workflow administrators who are not System Administrators regain access to the workflow screens.

Legal Hold Permission List Omitted Employees, and Sub-Table Rows Were Not Held

Reference #: 260916.100.0516

The list of people who could be granted the legal hold permission left out anyone who did not belong to an active security group, so they could not be granted it from that screen at all; the list is now judged on the employee's own active status instead. Separately, an existing sub-table row opened from the grid on a held record still offered edit and delete, because the row looked for a hold on itself while the hold sits on the parent record. Both have been resolved, so every active employee can be granted the permission and sub-table rows on a held record are protected like the rest of it. Nobody loses the permission, and people who already hold it are unaffected.

How will this affect users? Administrators granting legal hold permission, and anyone working on a record that is under legal hold.

An Inbound Message With No Sender Address Was Treated as a Known Employee

Reference #: 260916.100.0517

When a message arrived at the inbound email address without a readable sender, the previous version matched it to the first active employee who had no email address on file and then created records with that person's permissions. This has been resolved so a message with no sender is refused outright, and the same rule applies to company contacts. Every legitimate message carries a sender, so nothing that worked before stops working.

How will this affect users? Any customer using inbound email to create records; this closes a route by which an anonymous message could act as a real user.

Secure Email Missed Recipients and Sent External Participants a Broken Link

Reference #: 260916.100.0518

On some secure email threads a customer contact or vendor never received the notification carrying the link to the message, and nothing anywhere reported it: the rule that keeps the sender from emailing themselves compared record numbers without checking which kind of person they belonged to, so any external participant whose record number matched the sender's employee number was excluded. The Click to View Secure Email link in a reply notification also failed for vendors and customer contacts, because replies were built by a second route that contained a mistyped address, although the first message in the same thread was fine. This has been resolved so the sender is excluded by identity and every other participant is notified, and every message in a thread builds its notification the same way. Replying is now done in a panel on the thread rather than a separate pop-up window, message bodies are displayed inside a sandboxed frame, and the thread list shows the message count, the date of the last message and an acknowledgement indicator.

How will this affect users? Everyone using secure email, especially where vendors and customer contacts reply.

Notifications Showed Internal Names, and Some Opened Nothing

Reference #: 260916.100.0519

Notifications whose source had no friendly label printed an internal name at the user, and notifications not tied to a record area, including every request for a signature, had no link at all and rendered as plain text. This has been resolved so every notification reads as a plain area name on both the screen and the bell, which share one source and so cannot disagree, and every notification opens its proper destination, with a signature request opening My Assignments where the Sign now button is. A notification whose record has since been deleted now says the record was not found instead of opening a dead page.

How will this affect users? All users. Notifications are readable and clickable again on a screen everyone opens.

Notification and Alert Emails Left Out Sub-Tables, Branding and Links

Reference #: 260916.100.0520

A notification template that included a sub-table sent nothing for it, merged notifications arrived with an empty banner area, a configured custom banner image did not load at all, and record link, task link and action button placeholders typed into a workflow alert's own message reached the recipient as literal text. This has been resolved so a sub-table renders as a table in the email using the columns chosen for the template, limited to the rows belonging to the record and honoring the sub-table's own filter; the banner image, its alternative text and the site address configured for your email design are filled in, including on task alert emails; and workflow alerts expand link and action placeholders into real links and buttons, removing any placeholder that cannot be filled rather than sending it. A sub-table with no columns configured produces nothing rather than printing placeholder text to the recipient.

How will this affect users? Everyone receiving notification, task alert and workflow alert emails, and the administrators who author the templates.

Task Reminder Emails Carried Placeholder Text and Dropped the Alternate Address

Reference #: 260916.100.0521

Task reminder emails for contracts, solicitations, purchase orders, vendors, requests and employees went out with four unfilled placeholder markers visible in the message body, without the reference footer naming the system and the task, and without copying the alternate email address held on the task. This has been resolved so those markers are filled or cleared, the footer and the correct reply address for the record family are present, the alternate address is copied in both single and combined email modes, and a task reminder also raises the in-application notification in the bell menu, which date based alerts already did. Calendar invitations for tasks are now escaped the way the calendar format requires, so a body containing a comma, a semicolon or a line break no longer costs a recipient on a strict mail client the rest of the appointment; a resent invitation still updates the existing appointment rather than adding a duplicate.

How will this affect users? Everyone who receives task reminders or calendar invitations from Contract Insight.

Tasks Set to Complete Automatically Stayed Open

Reference #: 260916.100.0522

Tasks flagged to complete automatically were correctly skipped by the reminder run but were never closed, so they stayed open indefinitely and went on counting as outstanding. This has been resolved so both rules run: a task set to complete immediately is closed and its completion notice sent instead of the due date reminder, and a task set to complete on its end date is closed once that date is reached. Each closure records a history line saying the system completed it and sends the usual completion notice.

How will this affect users? Anyone using tasks configured to complete automatically, and anyone who reports on open tasks.

Sending a One-Off Email From a Contract Did Nothing, and Attachment Links Did Not Open

Reference #: 260916.100.0523

The one off email screen had stopped sending from contracts, and the links generated for attachments on those emails no longer resolved. This has been resolved so composing and sending works the same way from contracts, purchase orders, solicitations, requests and company records, and the attachment links open again. Recipients are chosen by typing into the To, Copy and Blind copy boxes with suggestions offered beneath, replacing the separate contact picker pop-up windows, and empty copy fields are left out of the message.

There is one case a link cannot cover. Where your system sends files as a download link and asks whoever opens one to sign in first, a recipient outside your organization has no account to sign in with, so the message arrives but the file will not open for them. The compose screen now names those recipients as soon as a file is ticked, rather than leaving the first sign to be a reader who never opened it, and offers Use secure email instead, which carries the subject and the message across and gives an outside reader a link they can open after signing in to the Vendor/Client Gateway.

How will this affect users? Anyone emailing from a record, particularly from a contract.

Exporting a Filtered List Returned Every Row in the Module

Reference #: 260916.100.0524

A list could be narrowed with a view, a search, column filters and a sort, and the export would still return every row the module held. This has been resolved so the Excel, CSV and PDF files carry exactly what the list currently shows, with dropdown and lookup values written out as their labels and a link back to each record.

How will this affect users? Every user who exports a filtered list, and anyone who has had to trim an oversized export by hand.

Filtering a List on a Yes or No Column Such as Active User Returned Nothing

Reference #: 260916.100.0525

On list screens such as Employees and Vendors / Customers, a dropdown field stored as a yes or no value displayed True or False in the cell, and filtering on it returned an empty list. This has been resolved so those columns read Yes or No, filter correctly and export with the same wording, so filtering Employees on Active User equals Yes, or Vendors / Customers on Active equals Yes, returns the expected records instead of nothing.

How will this affect users? Anyone filtering or exporting list screens that contain yes or no dropdown columns.

Record Rules on a Mass Process Job Selected No Records

Reference #: 260916.100.0526

When building the record rules for a mass process job, a rule over a dropdown that draws its values from another table stored an internal identifier while the job matched on the displayed text, so the rule selected no records at all. This has been resolved so those rules store the displayed value and select correctly; participant rules were always correct and are unchanged. A value the list no longer offers is kept in the picker and labeled as no longer on the list, so reopening an older rule does not silently discard it.

How will this affect users? Administrators building or reopening mass process jobs, including mass signing jobs.

No Way to Open the Record Behind a Row on a Report Built in an Earlier Version

Reference #: 260916.100.0527

Saved reports built in an earlier version ran without the hidden key that builds each row's drill-in link, so the action column was blank and there was no way to open the record behind a row. This has been resolved so those reports return the key and the View action appears on every row again. Reports built on a database view or a stored procedure still have no drill-in link, exactly as before.

How will this affect users? Anyone running a saved report that was built in an earlier version of Contract Insight.

The Reports List Showed Three Columns and Only the Reports Granted to You by Name

Reference #: 260916.100.0528

The reports list showed the report name, its creator and its created date, and listed only the reports granted to you personally. This has been resolved so Description, Gateway Type, Emailer Active, Created On, Created By and ID are shown again alongside the folder grouping, and the list includes every report you are entitled to: granted to you directly, granted to a role you hold, granted to a security group you belong to, or created by you. A saved search carried over from an earlier version, which has none of those properties, leaves those columns blank rather than guessing a value.

How will this affect users? Everyone using Insights, Reports, particularly anyone who receives reports through a role or a security group rather than a personal grant.

Opening the Value List on a Report Filter Locked Up the Browser

Reference #: 260916.100.0529

Opening the value list on a report filter for a column backed by a long list, such as an employee column, drew every option at once. Measured on a full size database, that took roughly eighteen seconds and could lock up the machine. This has been resolved so a long list renders only what is on screen, opens in about a second and offers the same values in the same order. A related fault that could drop the selection from the sort picker while editing was corrected at the same time.

How will this affect users? Report designers, most visibly on large databases.

Reports Built on a View Showed ID Numbers Instead of Names

Reference #: 260916.100.0530

When a report's source was a view rather than a table, its columns carried none of the field settings, so an employee or company column offered only the stored ID number. This has been resolved so those columns inherit the settings of the underlying tables, giving the resolved name, the same formatting and the same list of values a table sourced report has. Columns that cannot be matched to an underlying field keep exactly the behavior they had before.

How will this affect users? Report authors and readers working with view based reports see readable names in place of raw ID numbers.

Related Rows Under an Ad-Hoc Report Row Were Empty or Incomplete

Reference #: 260916.100.0531

The expandable block beneath a report row read no rows at all for most related lists because it matched on the wrong key, and where it did show rows it fetched the related table for the whole database up to a limit, so a record could show only some of the rows it actually has. This has been resolved so the block is keyed to the record it belongs to and asks only for the rows belonging to the records on the page.

How will this affect users? Everyone using ad-hoc reports that show related rows under the record.

An Ad-Hoc Report Joined to a Sub-Table Repeated the Parent Row

Reference #: 260916.100.0532

An ad-hoc report that joined a one to many child table showed the parent record once for every child row, so row counts and totals read high. This has been resolved so an affected report definition is repaired the first time it runs, without anyone having to open and re-save it. A definition that cannot be repaired safely is left exactly as it is rather than altered.

How will this affect users? Anyone running ad-hoc reports built over sub-tables; row counts and totals now reflect the parent records.

Report Output Did Not Match What Its Author Set Up

Reference #: 260916.100.0533

Several reports did not run or export the way they were designed. Some, in particular older saved searches, headed their columns with lower cased database names such as contract id; a field with Show On Report unticked was displayed anyway; numeric identifier columns were punctuated with thousands separators and decimals as though they were amounts; the workbook attached to a scheduled report email carried an extra column used internally to build each row's link; and a report selecting every column of a table collapsed into unreadable slivers. This has been resolved so columns carry the display name set in the designer in the run view and in the CSV, Excel and PDF alike, a column excluded from the report remains available for filtering and sorting without appearing on screen or in exports, identifiers read as plain numbers, the emailed workbook uses the same columns as a manual download, and past eight columns the result grid sizes each column to its content and scrolls sideways.

How will this affect users? Anyone running or exporting reports sees the column set and the headings the report's author intended.

Count Tiles on the Home Page Disagreed With the Lists They Opened

Reference #: 260916.100.0534

The count tiles at the top of the Home page counted deleted records, so the number on the tile did not match the list it opened. This has been resolved so each tile counts exactly what its list shows. These counts remain deliberately system wide rather than limited to what you personally may see, and they include inactive records, matching the lists they open.

How will this affect users? Everyone reading the count tiles on the Home page, particularly on Vendors and Employees.

An Assigned Dashboard Marked to Open First Did Not, and the Switcher Was Missing Dashboards

Reference #: 260916.100.0535

Ticking opens first against an assigned system dashboard had no effect, because the setting was never read back when working out which dashboard a person lands on, and the dashboard switcher offered only dashboards explicitly granted to you, so a user could have a full list of dashboards beside an empty switcher. This has been resolved so the opens first setting is honored across every route a person is assigned by, whether individually, through a role group or through a security group, and the switcher offers the same dashboards the list shows, including dashboards you own and system dashboards. The upgrade clears every existing opens first setting, so this is set once after upgrading; record scoped and gateway dashboards are excluded from the default, since they have no record to render against.

How will this affect users? Administrators assigning a landing dashboard, and everyone using graphical dashboards.

Graphical Reports and Dashboards Read From the Wrong Database and Carried a Trial Watermark

Reference #: 260916.100.0536

Only the first data source inside a graphical report or dashboard was pointed at the current system when it was opened, so a definition built against two sources could keep reading from another environment, and the reporting component's expired license stamped a trial watermark across the output. This has been resolved so every data source is repointed at the current system when the design is opened, and the license supplied with the product is used, so graphical reports and dashboards render real data with no watermark. Report and dashboard designers can no longer change a data connection, which keeps an author from pointing a design at a different database, and the designer toolbar carries a Save button rather than requiring the File menu.

How will this affect users? Report and dashboard authors, and anyone viewing graphical reports or dashboards.

Setting a Vendor's Default Dashboard Cleared an Unrelated Employee's Own Default

Reference #: 260916.100.0537

Naming a dashboard as the one that opens first on a vendor or company record also cleared the personal default dashboard of whichever unrelated employee happened to share that record's number. The employee received no signal; their dashboard simply stopped opening. This has been resolved so that step now runs only where it belongs, on the employee record.

How will this affect users? Employees whose personal default dashboard was being cleared without explanation.

Compliance Review Showed NA Risk Indicators, Red Grades for Unrated Companies and the Wrong List

Reference #: 260916.100.0538

On the Compliance Review screen every company's risk indicator read NA while still being colored green, amber or red from the real value on file; financial strength codes that mean the rating agency has no opinion, such as unavailable, undetermined and not quoted, were painted in the same red band as the worst graded score; and a user with access to companies but not to employees had the company list hidden from them rather than the employee list, so the only category they were entitled to was the one they could not reach. This has been resolved so the indicator shows the segment the feed supplied and reads N/A only when nothing was sent, unrated codes read as unrated in a neutral color while genuine grades keep the bands they had before, and each category is offered according to the user's own permission on that record type, with the Company Compliance Review and Employee Compliance Review menu items opening the category their label names. Where a screening feed recorded a match count but stored none of the individual matches, the record now reports the recorded figures and says the individual matches are not stored, instead of showing an empty panel that contradicts the list.

How will this affect users? Anyone reviewing company risk and compliance information sees accurate grades, and reviewers whose permissions cover only companies or only employees can reach their list.

The Default PDF Watermark Was Not Applied, and Watermark Edits Took Ten Minutes to Appear

Reference #: 260916.100.0539

Where a default PDF watermark is configured it was applied only through an explicit watermarked copy action rather than whenever a copy was taken; a watermarked copy that could not be stamped was handed over unmarked while still carrying a file name that said it was watermarked; and after the default was changed on Administration, Watermarks, the previewer and the tile covers on a record's Files tab went on showing the previous mark for up to ten minutes, or indefinitely where the default was edited in place. This has been resolved so the default watermark is applied whenever a record attachment is downloaded, opened in the browser or previewed, with the viewer's name, email address, telephone number and the date and time filled in for the person taking the copy; a watermarked copy that cannot be stamped fails with a clear message and is recorded rather than returning the unmarked original; and a watermarked page changes identity whenever anything drawn on it changes, including its text, tokens, font, color, size and image, so an edit appears the next time the document is previewed. Files that are not PDFs, and installations with no default watermark, are unaffected.

How will this affect users? Administrators maintaining watermarks, and anyone downloading or previewing PDF attachments at a site with a default watermark configured.

Saving Application Settings Could Overwrite a Password or an Unrelated Setting

Reference #: 260916.100.0540

On the Application Settings screen a password box loaded empty and saved whatever it held, so opening a password setting and pressing Update wrote an empty value over a working credential. A day count limit intended for the two log retention settings was also applied to two settings that are not day counts, so saving the screen overwrote the setting that allows persistent sessions with the value 1 and replaced the stored SharePoint password with 1. This has been resolved so an empty password box means leave the stored value alone, the retention limit applies only to the two genuine retention settings, and the number editor no longer imposes a minimum of zero on settings that use a negative value to mean no limit.

How will this affect users? End users are not affected as only System Administrators have access to these settings. Two ways of silently destroying a stored value are removed.

A Transfer Matching on a Long Value Reported Success and Changed Nothing

Reference #: 260916.100.0541

On the transfer screens a value longer than 35 characters was cut short before it was matched, so the transfer quietly changed nothing while still reporting that it had completed. This has been resolved so matching uses the whole value and only the display is shortened, and three further faults on those screens are corrected: a blank entry in the value list no longer produces a raw error when chosen, the task area now identifies its own records correctly, and employees missing a first or last name are listed under their sign-in name or record number instead of appearing as blank, unselectable entries at the top of both lists.

How will this affect users? End users are not affected as only System Administrators have access to these screens. Administrators reassigning ownership or replacing field values now get the records actually moved.

Imported Values Had Words Removed, and Unreadable Dates Were Stored as 1900

Reference #: 260916.100.0542

Importing rows into a record's sub-table stripped the words drop, insert, delete and update out of every value before saving, so a cell reading Software update license was stored as Software license with no indication anything had changed, and a cell holding a date that could not be read was counted as a success and stored as 1 January 1900. This has been resolved so values are written exactly as they appear in the file, and an unreadable date fails its own row with a message naming the column and the value. On a data import, a value that cannot be matched to a lookup list now fails its row with the field and the value named in the message, instead of being written into the record with an explanatory phrase appended to it. Numeric and yes or no cells are still cleaned of stray characters exactly as before, and a blank date still imports as empty.

How will this affect users? Anyone importing data; imported text now matches the source file and bad values are reported rather than written into records.

An Interrupted Index Update Could Take Search Offline Permanently

Reference #: 260916.100.0543

If an index update was interrupted, for example by the application being stopped part way through a write, an empty file could be saved into the stored copy of the search index. Once that happened, searching and all further indexing stopped for good and could not recover on their own. This has been resolved so empty files are never saved and never restored, a restored index is proved to open before it is trusted, and a damaged index is rebuilt rather than written over the last good copy. A record type whose own indexing pass is interrupted, and which is therefore left marked as still being updated, is released automatically and picked up by a later pass rather than staying that way until somebody notices. Two related faults are fixed at the same time: when the index cannot be read, the search screen explains that search is temporarily unavailable and offers Try again rather than showing a raw error or, worse, an empty result list that reads as no matches; and Rebuild from scratch on the search administration screen now clears the marker the indexer actually reads, so a rebuild genuinely re-indexes from the beginning.

The index itself is held on the application server's own disk and copied into your database as it changes, so it is restored automatically after a restart, a redeployment or a move to a different server rather than having to be built again from nothing.

How will this affect users? Every user of search, and administrators who rebuild the index.

Deleting a Default Folder Deleted Folders of the Same Name in Every Other Area

Reference #: 260916.100.0544

Deleting a folder from the default folder structure matched folders by name across every area at once, so deleting a folder under Contracts also deleted same named folders under Purchase Orders, Employees and Vendors / Customers, with no warning and nothing on screen to suggest it had happened. This has been resolved so the delete removes exactly the branch the confirmation names. Configuration already lost this way cannot be recovered by the upgrade, but it can no longer recur.

How will this affect users? End users are not affected as only System Administrators maintain default folder structures, but every record created afterwards receives the folders that were intended.

Survey Good and Bad Labels, Template Deletion and the Attach Survey Form

Reference #: 260916.100.0545

Per question Good and Bad results were compared against the wrong values, so most per question labels in version 22.x were incorrect; deleting a survey template left its sections, its question links and its reminder rules behind, and an abandoned reminder rule could go on queuing emails with no screen able to show or remove it; and the drawer for attaching a survey to a record opened empty. This has been resolved so Good and Bad are evaluated against the thresholds entered in the score key builder, deleting a template also removes its sections, question links and reminder rules whichever screen the delete was made from, and the attach survey form renders with both of its required fields reachable. A whole number question now says so and blocks Next when a decimal is entered instead of dropping the answer, and submitting a survey returns you to the record it hangs from rather than always landing on My Surveys. The numeric score itself is unchanged, so totals still match; only the Good and Bad label can read differently than it did in version 22.x. Surveys already sent from a template, and the answers they carry, are deliberately left alone.

How will this affect users? Anyone sending or answering surveys, and anyone reviewing survey responses.

Assigning Several Security Groups to an Employee Granted Only the First

Reference #: 260916.100.0546

On the employee permissions screen, selecting several security groups and assigning them granted only the first group selected, while the audit entry claimed all of them had been assigned. This has been resolved so every selected group is assigned exactly once. Roles and departments were never affected by this.

How will this affect users? End users are not affected as only System Administrators grant security groups. Grants that used to be silently dropped now land.

License Levels Offered Permissions They Cannot Hold and Changes That Exceeded the Seats Purchased

Reference #: 260916.100.0547

On sites using enhanced licensing the employee permissions screen offered security groups and individual permissions that the person's license level cannot hold, so a read only account could be offered the permission to add contracts; and changing an employee to a license level with no free seats told the administrator there were no licenses available and then applied the change anyway a moment later, so a client could silently exceed the seats they had purchased. This has been resolved so entries a license level cannot hold are grayed out with the reason shown on hover and refused if attempted anyway, and a change to a level with no free seats is refused with nothing written. The seat counts and the rule that only levels your license sells sessions for are offered are unchanged.

How will this affect users? End users are not affected as only System Administrators have access to these settings. Clients relying on accurate seat usage are protected.

A Record's Already Linked List Showed None of Its Links

Reference #: 260916.100.0548

The already linked list on a record left out any link whose target record fell outside a restricted view, so a record with several linked contracts could display none of them, which also meant the same link could be added again and again with no warning. This has been resolved so the list reads every link that exists, resolving names through the usual permission filter. Adding and removing links is unchanged, including the rule that some pages refuse a duplicate pair.

How will this affect users? Anyone working with linked contracts, requests, purchase orders, solicitations and vendors.

Finding a Record to Link Searched Only Its Title

Reference #: 260916.100.0549

Linking a record offered a search on the title and nothing else, so a record could only be found by name. This has been resolved so a Find where field picker covers the target record's own fields, with the right value control for each kind of field: contains for text, a range for dates and for numbers, a choice list for dropdown fields and yes or no for check boxes. Either end of a range now filters on its own, results carry the value of the field they were found by formatted the way that field normally reads, the list says how many were found and when only the first 200 are shown, a record with no title of its own reads as no title rather than repeating its number, and a date range includes everything recorded on the last day of the range.

How will this affect users? Anyone linking contracts, purchase orders, solicitations or requests to one another.

A Record's Folder Tree Collapsed to One Folder, and Five File Columns Were Missing

Reference #: 260916.100.0550

On a record that had received inbound email, the Files area could show only the Email Files folder while the header counted several more. Five columns that version 22.7 carried on the file list, Notes, Collaboration Type, Checked Out To, Last Viewed By and Last Viewed Date, were also unavailable. This has been resolved so the tree always starts from the record's own root folder, every folder and sub-folder is listed again and the Email Files folder can be opened and browsed like any other, and all five columns are offered again. A column appears when the folder you have open has something to put in it, a column chooser beside the view switch shows or hides any of them with each entry saying whether it holds data here, and your choices are remembered per record type. On solicitations the collaboration column reads Yes or No under an Is Public heading as it did before, the file search now covers notes as well, and a folder whose parent no longer exists is shown under the root rather than disappearing from the tree.

How will this affect users? Anyone working with a record's attachments.

Bulk Attachment Uploads Were Not Scanned and Could Reach Only a Fraction of Contracts

Reference #: 260916.100.0551

The bulk attachment upload screen wrote files without the virus scan, the stored file handling and the audit entry that a record page applies, and its contract picker read a filtered list that drops any contract whose owner record is missing or deactivated, so those contracts could not be chosen at all on a tool whose entire purpose is filing attachments onto contracts. This has been resolved so bulk uploads go through the same path a record page uses and the picker lists every contract.

Administration, Bulk Import Attachments also stages the batch before anything is written: the files you drop or browse for are listed first, you choose whether to hold them in the pending list or file them straight onto one record, and a confirmation says what is about to happen. Every file lands in the pending list before it is filed, so a batch that stops part way leaves its files safely pending rather than half attached, and the pending list has its own action to file a selection onto a record later. A file somebody else has already filed is left where it is rather than moved out from under them.

How will this affect users? Administrators can file bulk uploaded attachments onto any contract, and those files are scanned and audited like every other upload.

Ratings Saved Without a Contract, and a Company's Own Ratings Could Not Be Reached

Reference #: 260916.100.0552

Ratings added from a record were saved with no contract on them, because the contract list on the rating form was showing the wrong set of contracts and could also drop the value that had been filled in for you. Ratings recorded against a company itself could only be reached from a contract, so a company's own ratings had nowhere to be read. This has been resolved so the contract is filled in and saved correctly, the ratings list shows the contract title rather than a bare number, View Ratings opens the record's existing ratings with search, export and New above the list instead of going straight to a blank rating form, and the company record carries a Score Card tab with the full list plus add, edit and export. A rating added from a contract is still recorded against the company, with the contract filled in.

How will this affect users? Anyone rating vendors, companies or contracts, and anyone reviewing rating history or scorecards.

The Financial Summary and Running Totals Were Missing Under a Contract's Transactions

Reference #: 260916.100.0553

The single row summary that sits above a contract's transaction list, showing budget, income, expense, balance and percentage used, was not shown, and the totals under a related list appeared only on the classic tab layout and were added up from the rows currently loaded rather than from the whole list. This has been resolved so the summary appears on both record layouts, read from the same source version 22.7 read so the figures match to the cent, including the cases where income raises the remaining balance and where the percentage used is negative, and totals under a related list are calculated across the whole list on both layouts. Totals are matched to the specific list being shown, so two panels drawing on the same related table no longer share a figure, and a contract with no financial transactions shows no summary, as before.

How will this affect users? Anyone reviewing contract financials, or reading totals under any related list.

The Notes Tab Raised an Error and Notes Took Two Clicks to Save

Reference #: 260916.100.0554

Opening the Notes tab on a record that had no notes, or before a note had been selected, produced an error rather than an empty state and could interrupt the screen you were working on; the Save Note button stayed disabled while somebody was typing, so the first click only moved focus out of the editor and the note saved on the second; and a note longer than the eight thousand character limit simply did nothing when saved, with no message. This has been resolved so the tab opens cleanly in every state, a note saves on the first click, and the notes form shows how many characters are left once a note passes three quarters of the limit and says how far over it is. The limit is the same as before and the same notes are refused; the difference is that the writer is told why.

How will this affect users? Anyone writing notes on a contract, request, solicitation or vendor record.

New Records Opened With Employee Assigned and Department Empty

Reference #: 260916.100.0555

A new record opened with Employee Assigned and Department empty. This has been resolved so both are filled in again from the signed in person and their department, along with the chosen record type, using the same per area settings that decide whether the department is defaulted for contracts and requests. A value carried over from a source record when creating from context still takes precedence, and the record's own key field is never touched.

How will this affect users? Everyone adding records.

Fields Outside a Field Group Could Not Be Placed, and Unused Fields Could Not Be Deleted

Reference #: 260916.100.0556

In Tab Details Setup the field group list excluded fields that had never been assigned to a group, so a large part of an area's field set could not be placed on a record tab at all. Separately, the check that stops you deleting a field used by a calculated column matched far too widely, blocking fields that no calculated column refers to. This has been resolved so the group list offers an entry for all ungrouped fields, as version 22.7 did, and the delete check matches exactly and names the calculated column standing in the way instead of merely asserting that one exists. A group already displayed by another panel on the same tab is removed from the list so two panels cannot draw the same fields, a panel that was never finished being set up is skipped rather than drawing an empty card on the record, and if the usage check cannot be completed at all the deletion is refused rather than allowed to proceed.

How will this affect users? End users are not affected as only System Administrators lay out record tabs and maintain fields.

Editing a Workflow Condition Could Silently Change Which Field It Tests

Reference #: 260916.100.0557

Each row inside a workflow condition had its own field picker that defaulted to whichever field sorted first, so editing a Status condition could quietly turn into a rule about a completely different field. This has been resolved so the field is chosen once, above the rows, and every row in the condition is about that field, which is what a rule such as any of these statuses needs. A column whose values come from a list now offers Equal and Not Equal only, because a contains test on an identifier column also matched longer numbers and returned the wrong records.

How will this affect users? End users are not affected as only administrators author workflow conditions.

Finished Tasks Still Offered Approve and Complete, and a New Task From a Task Had No Parent

Reference #: 260916.100.0558

A task that had already been completed or rejected went on offering its status actions; creating a new task from inside an open task produced a task with no parent record, which then appeared on no screen and could not be managed; and the employee task delegation screen showed a message about missing required fields and saved the incomplete rule anyway. This has been resolved so status actions are withdrawn on a closed task in all three places they appear, each saying why, with the check repeated at the moment a status is applied so a grid left open on another screen cannot push a status onto a task that has since closed; a task created from a task belongs to the same parent record, and the item is not offered where the task itself has no parent; and a delegation rule cannot be saved until the task type, field, condition and delegate are all present.

How will this affect users? Anyone processing tasks, and administrators setting up task delegation.

Numeric, Masked, Hyperlink and Code Fields Displayed or Saved Incorrectly

Reference #: 260916.100.0559

Four kinds of field did not behave correctly on a record form. A numeric field with no thousands or decimal separator configured failed rather than following the system's regional settings; opening and saving a record wrote a masked field's own punctuation into a field nobody had typed in; fields configured as hyperlinks or email addresses could not be edited at all, which included the employee email address; and a code held in a fixed width column is padded with spaces behind the scenes, so the lookup for its label missed and the raw code was shown in place of the friendly name. This has been resolved for all four: numeric fields fall back to the regional separators and fields configured with their own separators display and save correctly, an empty masked field stays empty, hyperlink and email fields display as a link when reading a record and as an editable box when editing one, and labels resolve for fixed width code columns in grids and on forms. The number of decimal places is still fixed by field type, exactly as before, and one list, the vendor product and service codes, still shows its raw code.

How will this affect users? Anyone entering or reading values on a record form.

Pausing a Scheduled Job Did Not Stop It

Reference #: 260916.100.0560

Setting a scheduled job's interval to zero on the Scheduled Jobs screen reported that the job was not scheduled while the engine quietly kept running it at its minimum interval. This has been resolved so a zero interval really pauses the job using the job's own active setting, and entering a positive interval again resumes it; the interval the job had before is kept rather than overwritten with zero. Running a paused job by hand still works, and the history panel for a job now reads that job's own run history and returns its most recent entries immediately.

How will this affect users? End users are not affected as only System Administrators pause and resume scheduled jobs.

Records Missing From Lists Because a Related Record Was Missing

Reference #: 260916.100.0561

Contracts whose owner was empty, or whose owner record had been deleted, were excluded from list results, so those records were simply missing from the list. This has been resolved so list rows are read from the record table itself, with related information such as owner, status or type names joined on only for display, and a record can no longer disappear from its list because a related record is missing. Permissions, deletion and filters are applied exactly as before.

How will this affect users? Anyone listing or searching records, and anyone relying on list totals and counts being complete.

Choosing a Display Language Did Nothing, and English Could Not Be Chosen Back

Reference #: 260916.100.0562

Choosing a language from the header appeared to do nothing, and choosing English again did not enable Apply for anyone whose browser had been cleared or who signed in from a second machine while a language was saved against their account, leaving no way back to English at all. This has been resolved so choosing a language translates the screen in place with no reload, keeps later content translated as you move around, and saves the choice against your account, and choosing English enables Apply and clears the saved language. Grid data cells and values you have typed are never translated.

How will this affect users? Users who work in a language other than English.

Map Location, Online News and News Alert Actions on a Company Record Did Nothing

Reference #: 260916.100.0600

View Map Location, View Online News and Create News Alert sit on the Actions menu of a company or vendor record and hand off to an outside mapping and news service in a new tab. Their addresses were written for an unencrypted connection, which current browsers refuse to open from a secure page, so all three did nothing at all when they were clicked, and the company name was passed across without being encoded, so a company whose name contains an ampersand, a hash or a plus sign was looked up under a truncated or mangled name. This has been resolved so all three open over a secure connection and carry the company name whatever characters it contains.

The map is built from the parts of the address the company actually holds, using its coordinates where they are recorded and its address otherwise, rather than joining every part whether or not it has a value. Where a company has neither an address nor coordinates, or no name at all, the action is shown disabled with the reason given rather than opening an empty search.

How will this affect users? Anyone researching a company or vendor from its record.

A Risk Warning Naming a Missing Field Stopped the Record From Opening

Reference #: 260916.100.0601

Risk warnings are evaluated against a record when the record is opened. Where a warning named a field that had since been renamed or removed, the evaluation failed for the whole record rather than for that one warning, so the record itself would not open. This has been resolved so a warning that cannot be evaluated is passed over and the record opens with its remaining risk findings.

Because a broken warning is now quiet rather than obvious, administrators who rename or remove fields should check their warnings afterwards using the Try it panel on the Risk Warnings screen, which runs the warnings against one record you name and lists what fires.

How will this affect users? Anyone opening a record covered by risk warnings, and the administrators who maintain them.

Copying a Navigation Menu Produced a Flat List of Orphaned Items

Reference #: 260916.100.0602

Creating a workspace as a copy of an existing one copied its menu items but left every copied item pointing at a parent that exists only in the workspace it came from, so the new workspace arrived as a flat list with none of its structure and had to be rebuilt by hand. This has been resolved so a copy reproduces the whole menu tree, each copied item sitting beneath its copied parent. The choice is made on the new workspace form on Administration, Navigation Menu, where Start from offers an empty menu or a copy of any workspace that has items, with the item count beside each one.

Deleting a workspace also clears up after itself now. Its menu items and its employee assignments are removed with it, rather than being left behind where no screen could show them, and a workspace that still has employees assigned is refused with a count of how many, so nobody is moved onto a different menu without being told.

How will this affect users? End users are not affected as only System Administrators maintain navigation menus. Administrators building a variant of an existing menu, which many will do while reviewing their menus after upgrading, get the whole tree.

Creating a Field Whose Name Contained Spaces or Punctuation Reported a Failure

Reference #: 260916.100.0603

A custom field's storage name is built from the display name it is given. Where that name held spaces, punctuation or symbols, the name the screen expected and the name the database actually created could differ, so a field could be created and then reported as having failed, and the check for an existing field of the same name looked at the wrong name. This has been resolved with one naming rule that the screen and the database both follow: a character that cannot be stored becomes a single underscore, runs of underscores are reduced to one, and a name that would otherwise begin with a digit is prefixed. The screen asks the database what the name will be rather than predicting it, so the two cannot disagree.

The correction was written for the previous version but was never included in a release, so it reaches customer systems for the first time in this upgrade. Fields that already exist keep the names they have and are not altered.

How will this affect users? End users are not affected as only System Administrators create fields. Administrators can name a field the way the business names it, including an ampersand, an apostrophe or a space.

Core System: VISDOM AI

Questions asking for a list or a count of records returning an apology instead of an answer

Reference #: 260916.200.0500

In the VISDOM assistant, a question such as "provide a list of the contracts expiring in the next 30 days" could come back as an apology rather than an answer, because the query written to answer it referred to data that does not exist on your system. This has been resolved so those questions build a valid query against your own data, including questions that depend on the fields your organization has added, for example finding contracts where a warranty clause has been captured in a field.

Answers that return records are now shown as cards, each with a heading, the values found and a link to the record, rather than as a page of unformatted data. The first three are shown with the rest behind a Show the other control, the results can be downloaded as a spreadsheet, and an empty value is shown as blank instead of reading as the word "null". Questions of this kind are answered by the Reports choice in the assistant's picker, which is also selected for you when the picker is left on Auto.

How will this affect users? Anyone who asks the assistant for a list, a count or a figure drawn from record data will now receive an answer built from that data, presented as records that can be opened from the answer.

Document not attached, and its extracted clauses lost, when a record is created with VISDOM on sites that store files in cloud storage

Reference #: 260916.200.0501

On sites configured to keep documents in cloud storage, creating a record from a document with Create with VISDOM saved the record, its field values and its obligations, but reported that the file could not be attached. Because a clause is stored against the document it came from, the whole reviewed clause set was discarded along with the attachment, so a review in which every clause found had been kept could still end with a record holding none. This has been resolved so the document is attached on those sites and the clauses are saved with it. The same correction applies to document generation, signature packages and quick signing.

If an attachment does fail for any other reason, the save now states how many clauses were affected and how to recover them, and an obligation that fails to save is reported in the same way. Obligations no longer depend on the attachment at all, so a user without permission to attach files keeps the obligations VISDOM found in the document. Clauses still require the document, because the source file is part of the clause record.

How will this affect users? Users at organizations whose documents are held in cloud storage will have the document attached and the clause and obligation findings kept. Users without file attachment permission will no longer lose obligations without being told.

Clause extraction returning categories that have nothing to do with the type of record being processed

Reference #: 260916.200.0502

Where more than one set of clause categories is trained for an organization, documents read by VISDOM were classified against all of them rather than against the set configured for the record type being created, which produced clause categorizations unrelated to the record in hand. This has been resolved so clause extraction classifies a document against the clause categories configured for that record's own type. A record type with no clause categories configured falls back to the common clause set, so extraction still returns findings rather than silently returning none.

How will this affect users? Users at organizations with more than one set of clause categories will see clause findings categorized to the record type they are working in. Organizations with a single set will see no change.

VISDOM extraction features selected for one document reset to every feature on the next document

Reference #: 260916.200.0503

The extraction features chosen in Select features were not kept. The next document opened with every feature selected again, overriding both the company default set on the VISDOM Configuration screen and the person's own last choice, which had been saved correctly a moment earlier. A profile with clauses and obligations both switched off was read as nobody having chosen anything, so the clause, sentiment, risk, possible additions and obligation passes were switched back on over a deliberate decision. This has been resolved so a saved selection is used on the next document, and a person who has never made a selection starts from the company default.

How will this affect users? End users who limit which analyses run will keep that choice from one document to the next, and administrators who set a company default will see it applied to people who have not chosen for themselves.

VISDOM reporting that it could not be reached, or failing part way through an extraction with an expired credential message

Reference #: 260916.200.0504

VISDOM chat, clause extraction and document analysis could report that VISDOM could not be reached, even though the stored authorization still claimed to have time left on it, and a long extraction could fail part way through with an expired credential message when the shared authorization was renewed by another process while the document was being read. This has been resolved so Contract Insight recognizes an expired authorization in both of the forms the service returns it, obtains a current one and repeats the call once. Document extraction obtains a current authorization for each call and is covered by the same recovery. If the authorization is genuinely finished, further attempts pause for a minute rather than calling the service repeatedly, and a timeout or a service error deliberately does not trigger a renewal, since that would discard an authorization that is still working.

How will this affect users? End users will see the answer or the extraction complete instead of an unexplained failure. Administrators no longer need to re-authorize by hand after a temporary failure.

Create with VISDOM warning that work would be lost after the record had been saved, and never opening the new record

Reference #: 260916.200.0505

Pressing Save on Create with VISDOM created the record and then warned the reviewer that the work was about to be discarded, leaving them on the review screen rather than on the record. Pressing Save a second time could create a second copy of the same document. This has been resolved so Save opens the record it has just created, the warning no longer fires on the application's own navigation, and the back arrow is the way to return to the record from the review screen. Save & create another still starts a fresh review.

How will this affect users? End users creating records from documents will be taken to the new record when they save, and can no longer create a duplicate record by pressing save twice.

Fields with AI field extraction cleared still arriving filled in from VISDOM

Reference #: 260916.200.0506

Clearing AI field extraction for a field in Field Management only took effect after an administrator re-ran the field synchronization, so system maintained fields such as Expiration Warning Date and Date Entered could arrive filled in on a review form, on a read only field the reviewer could not correct. This has been resolved so the setting is applied wherever a value reaches the form, whichever part of the analysis produced it, including the trained extraction and the follow up questions VISDOM asks of a document. If the field settings cannot be read at all, nothing is filtered rather than everything being blocked, so a temporary problem cannot turn every extraction into an empty form.

How will this affect users? Administrators decide which fields VISDOM may fill and the decision now takes effect immediately. End users will not be offered values on fields their organization has excluded from extraction.

Showing an extracted value or a clause in the source document unable to find the text, or returning to page one immediately after arriving

Reference #: 260916.200.0507

Asking to see an extracted value or a clause in the source document failed whenever the document used curly quotes, long dashes, non breaking spaces, soft hyphens or ligatures, because the text being searched for was plain typed characters. The view could also land on the right page and then return to page one a moment later, because drawing the highlight changed the width of the pane slightly and the document refitted itself. This has been resolved so matching ignores those typographic differences, falls back to a close match when an exact match is not available and reports how it matched; dates and similar values are now shown in the document's own wording so they can be found. The document stays on the page it found, and automatic fitting happens only when the pane genuinely changes width, restoring the page being read.

Very short pieces of text are still refused, because they occur throughout a document, and a locate control that cannot work, for example one offered against a summary rather than a quotation, is now disabled with the reason shown rather than searching and finding nothing. Numbered lists in VISDOM answers also continue their numbering across a blank line or a sub bullet, instead of a list of ten steps reading as several lists of one.

How will this affect users? Anyone checking a VISDOM finding against the source document will be taken to the passage and left there.

The document taking little more than half the available width on the VISDOM workbenches, and the screen appearing to reload while typing

Reference #: 260916.200.0508

On Create with VISDOM and Edit with VISDOM a wide empty band sat between the document and the VISDOM panel, leaving the document little more than half the width it had to work with. Typing in the document could also make the screen appear to refresh itself or lose its connection, opening a second document without leaving the screen produced an error, and a tracked change was recorded against "Guest user" rather than the person who made it. All of these have been resolved. The VISDOM panel now opens at a task pane width rather than taking most of the screen, so the document keeps the larger share of it, and the document opens fitted to the width of its pane instead of occasionally opening clipped mid line while the zoom reading said 100 percent. Typing no longer causes a round trip for every keystroke, the editor is released properly when another document is opened, and a tracked change carries the name of the signed in user. The width presets and the drag handle still override the starting width.

How will this affect users? Users reviewing documents on the VISDOM workbenches, particularly on laptop screens, will see more of the document, and a tracked change can be attributed to the person who made it.

A dropped connection returning the VISDOM workbench to the record picker, and a queued document opening an empty drop area

Reference #: 260916.200.0509

Choosing Create with VISDOM for a document held in My Pending Files worked once and then presented an empty drop area until the browser was refreshed, and if the browser's connection to the server dropped in the middle of a review, for example when a laptop lid was closed, the workbench returned to the record picker. This has been resolved so the staged document is identified in the page address and survives a reconnection, a refresh or the link being opened in a second tab, and a reconnection returns to the same record and the same document. The period during which a reconnection is accepted has been widened, and the screens that show findings as they arrive are no longer at risk of being closed by the volume of updates. A document that cannot be opened, because it has been deleted, has already been filed onto a record or belongs to someone else, now says so instead of presenting an ordinary looking empty drop area.

How will this affect users? End users can return to a long review after a disconnection and can start a review from My Pending Files as often as they like, in as many tabs as they like.

The negotiation brief asking the counterparty to correct data held on your own record

Reference #: 260916.200.0510

Where VISDOM found a disagreement between the values on your record and the wording of the document, the negotiation brief could turn that disagreement into a request addressed to the counterparty, for example asking them to rename the agreement or to change a price so that it matched an internal budget figure. This has been resolved so every disagreement of that kind is listed under a Check on our side heading, which states what the record says, what the document says and asks which of the two is correct. The points to raise with the counterparty are drawn from the clause findings alone.

How will this affect users? Users producing a negotiation brief from the VISDOM workbenches will see internal data questions kept separate from the points to put to the other party.

Change in Behavior: The VISDOM Assistant No Longer Answers Questions About a List or Grid Page

Reference #: 260916.200.0511

In the previous version the always available assistant was given the contents of a list page, as the user had narrowed it, together with computed totals, so that it could answer questions about many records at once. That has been removed, because at that size the answers drifted from the data on screen often enough that a reader could not tell a correct answer from a plausible one, and a list question is exactly the case where the answer cannot be checked by eye. The assistant still receives the full context of a record page, and answers as a general assistant on a list page. To ask a question across many records, choose Reports in the assistant, which queries your data and shows the query it ran.

How will this affect users? Users who asked the assistant about what was on a list or grid page will use Reports for those questions instead, and will receive an answer drawn from the data with the query shown alongside it.

Change in Behavior: The Clause Sentiment, High Risk and Possible System Additions Options Now Decide Which Analyses Run

Reference #: 260916.200.0512

These options are chosen before a document is analyzed, and they now decide whether those analyses run at all. In version 22.7 they only hid the tabs that displayed the results, so every analysis ran on every document even when the features were switched off. Turning an option off now saves processing time and VISDOM usage; turning one on gives exactly the same analysis as before.

How will this affect users? End users will see no difference in an analysis they have switched on. Administrators watching VISDOM usage will see work no longer performed for features nobody has asked for.

Change in Behavior: Create with VISDOM Opens With the Analysis Features Your Administrator Has Chosen

Reference #: 260916.200.0513

Create with VISDOM no longer expects a reviewer to go looking for the analysis features before a document is read. It opens with the set of features your administrator has chosen as the starting point on the VISDOM Configuration screen, so where that set includes the analysis passes, a reviewer who changes nothing is given clause findings, risk findings, sentiment readings and obligations alongside the field values, instead of field values alone. To give a sense of the difference, on one document used in our own testing that was nine field values on their own against nine field values plus eighteen clauses, three risk findings, eleven sentiment readings and nine obligations. The Select features choices still apply and are remembered from one document to the next, and the summary line now names in plain words what is about to run and lists what has been switched off.

How will this affect users? End users, and first time users in particular, will get the reading of a document their organization has asked for without having to find the feature list first. Anyone who has chosen a shorter set of features keeps that choice.

Change in Behavior: The Record Type on Create with VISDOM Is Chosen on Each Document, Not by a System Setting

Reference #: 260916.200.0514

The record type picker on Create with VISDOM now always carries Let VISDOM choose the type as its first option, for everyone. Choosing it has VISDOM read the document and decide; choosing a type directly skips that step. The system wide setting that made this decision for everybody is no longer read, so an organization that had it switched on will now see the choice offered on each document. Nobody loses the capability, and a record type is still required.

When VISDOM cannot work out what kind of document it is reading, the screen now returns to the opening step with the document still staged, names the document and asks for a record type. The previous version selected the first record type in the list without saying so, which built the record from the wrong set of fields. A type that VISDOM has chosen stays editable rather than being locked, is marked in the picker as VISDOM's with a note of the reading the model gave and how closely it matched your configured types, and changing the type asks for confirmation and then runs the analysis again, because the extraction is driven end to end by the type.

How will this affect users? End users creating records from documents decide per document whether VISDOM picks the type, and an unrecognized document costs one click instead of producing a record built on the wrong type. Administrators who had set the automatic option for everybody will find the same capability offered in the picker.

Change in Behavior: The VISDOM Brief Is Written When It Is Asked For, and Held for an Hour

Reference #: 260916.200.0515

The VISDOM Brief on the Home screen is written when you ask for it with Brief me on my day. Nothing is generated by landing on the Home screen, so the page does not pay for work nobody has asked for. Once written, a brief is held for an hour and survives a browser refresh, so passing through Home several times in a morning shows the same brief immediately rather than writing a new one each time. Regenerate always replaces what is held.

How will this affect users? Users see a brief when they ask for one, and see it again instantly for the rest of the hour. The brief is offered only to people for whom the AI assistant is enabled.

Negotiating comment and business justification saved into each other's fields when a clause was captured from a document

Reference #: 260916.200.0520

In version 22.7, saving a clause found in a document with Add Clause(s) with VISDOM wrote the negotiating comment into the business justification field and the business justification into the negotiating comment field. The screen's detail pane labeled the two the same way round, so nothing on screen showed that they had been exchanged. This has been resolved on the screen that replaces it, Extract Clauses with VISDOM, reached from the Clause Library; the Negotiating comment and Business justification boxes each save to the field they are named for, and each is shown under its own label wherever the clause is read afterward.

Clauses captured this way before the upgrade keep the values that were stored for them, so a library built with that screen may hold the two pieces of text the wrong way round. They can be corrected by opening the clause in the Clause Library and editing the two fields.

How will this affect users? End users capturing clauses from documents will find each entry saved under the heading it was written for. Anyone who built clauses this way in the previous version should check the negotiating comment and the business justification on those clauses, because values stored before the upgrade are unchanged.

Module: Document Collaboration & E-Signature

Word documents sent for signature could not be opened or signed

Reference #: 260916.300.0500

A signature package started from a Word or Excel document is now converted to PDF when the package is created, and the layout placeholders an author used to mark where fields belong are removed first so that they do not print underneath the real signature blocks. Documents already in the system are converted for display when they are read, so the field placement canvas, the page images in the signing viewer and the final stamped copy all show the document's pages. Previously a Word file produced no pages at all and no error, so the placement screen showed an empty canvas, the signing viewer had nothing to click, nothing could be stamped, and the Signing Portal could not display the file. Reference files are the exception; they are read alongside the document and keep their own format. Where a file genuinely cannot be opened, the screen now says so instead of showing an empty canvas.

How will this affect users? Signers receive a readable document with clean signature blocks, and anyone placing fields on a Word document sees its pages. Approval packages are deliberately unchanged, since an approver still downloads the editable original to mark up.

Approval and signature invitations did not reach participants who are not employees

Reference #: 260916.300.0501

Participants who are not employees now receive their invitation with a link to the Signing Portal. Company contacts, external email addresses and e-signature contacts are all invited alongside employees. The Sign Document(s) and Review Document(s) buttons in those emails now carry each participant's own portal link, which resolves the file cannot be found message some recipients received, and Contract Insight will no longer build a link from an incomplete portal address, falling back to a working in-application action rather than producing an address that leads to a page that cannot be found.

How will this affect users? External approvers and signers receive their invitation and can act on it, and the staff who route documents outside the organization no longer have to chase invitations that were never sent.

Signature fields placed on a document had no effect on what the signer was shown

Reference #: 260916.300.0502

A document can either be signed wherever the signer chooses to click, or only on the boxes the sender placed. When both settings were in force at once, the portal told the signer to click anywhere and never drew the placed boxes, so a carefully positioned layout saved, reloaded correctly for the sender and had no effect whatever on what the signer was shown. This has been resolved so that placing a signature field switches the document to signing on placed fields, and a process created on a document that already carries an author's fields is set that way from the start. The fields an author laid out are now copied onto the signing request and matched to the right participant when the process is set up, and re-choosing documents does not duplicate fields already placed. The sender can still choose the signing mode on the setup screen, and the placement screen states which of the two is in force.

How will this affect users? Layouts now reach the signer exactly as they were drawn, instead of arriving as an unmarked document.

Required and optional signature fields were reversed, and a required signature box could not be completed

Reference #: 260916.300.0503

When a document that already had signature, date and text fields laid out on it was set up for signing, each field's required setting was copied across backwards, so a field the author marked required reached the signer as optional and one left optional was enforced, and the mistake only became apparent afterwards on the returned document. Separately, a signature box marked required could never be satisfied at all, because the portal counted it as unfilled even after the signer had signed it, a signature being stored as an image rather than as typed text; the document stayed pending, the step that completes the signing never became available and the signature the signer had given was ignored. This has been resolved so that the author's own setting is carried through to the signer, and a signature box is no longer stored as required. The portal already refuses to finish a document while a signature box has not been signed, so nothing is weakened, and the field settings panel now explains this instead of offering a switch that would stop the process being completed.

How will this affect users? Authors laying out fields get the behavior they set, and processes that previously stalled at the final step can be completed. Packages already in flight keep the values they were recorded with, so nobody is asked for something different half way through a signing.

A group containing only optional approvers notified nobody and the process never moved

Reference #: 260916.300.0504

An optional approver is deliberately not invited when a process starts or when a group is reached, and is invited the moment somebody publishes a new version of the document. Optional approvers were being marked as notified at the start without being emailed, so they were never invited then and could never be invited afterwards either, and a group holding only optional approvers notified nobody, left nobody able to act, and sat active for ever with the group appearing to have been skipped. This has been resolved so that a group of only optional approvers is invited and can act, and an optional approver is marked as notified only when the invitation is actually sent, with the invitation carrying the explanation that changes were made. Where a group does contain a required approver, nothing changes and optional approvers are still passed over as before.

How will this affect users? Optional approvers, including vendor contacts, receive their invitation when the document changes, and an approval process made up of optional approvers proceeds instead of stalling permanently.

Approval links for a process started from a file on a record opened the Home page

Reference #: 260916.300.0505

A process started directly from a file on a record carries that record on the process itself rather than through a generated document, and three places read only the generated document. An employee clicking an emailed approval link landed on the Home page with no indication of what they had been asked to do, the in-application alternative link pointed at the site address itself, and informational notices left out the record they referred to. All three now resolve either kind of process, so the link opens the document the recipient was asked to act on.

How will this affect users? Approvers and signers whose requests were raised from a file on a record, including processes already running at the time of upgrade, land on the right document.

People listed to be told about a process received nothing, and a rejection told nobody

Reference #: 260916.300.0506

An approval or signature process carries two lists of people who do not act on it but need to know that it moved, Employees to tell and Company contacts to tell. Both could be edited on the setup screen and neither had ever been sent anything. They now receive informational notices when a process starts, when the next group is invited, when it completes, when it is rejected or declined, when a comment is posted and when a new version is published, matching which audience each event reached in version 22.7; employees receive a link to the process console and company contacts receive a view-only link to the Signing Portal. In the same area, rejecting an approval or declining a signature now emails everyone on the package who had already been invited, including the people who had already approved and who otherwise had no way of learning that what they had signed off on had been thrown back.

How will this affect users? Process owners and interested contacts are kept informed without being made participants, and approvers, signers and owners are told when a package is rejected or terminated.

Approval groups took no version snapshot, and a completed approval produced no final version

Reference #: 260916.300.0507

Starting an approval now attaches the document's published files to the approval package, and as each group completes, its versions are copied forward to the next group, so every group approves the document as it stood when its members were asked. Where a group is set to accept tracked changes on completion, the copy handed to the next group has the previous group's tracked changes accepted first, so reviewers receive a clean document, and a file that cannot be read is carried forward unchanged rather than lost. When the last group finishes, the approved Word files are archived and republished as a new version named after the document with from E-Approvals appended, which becomes the file's final version; if the final group accepts tracked changes, that copy has its changes accepted and its editing restrictions removed first, because the review is over. PDFs and spreadsheets keep the version they already had.

How will this affect users? Approvers review the document as it was when they were asked, and anyone reading the result afterwards has a clearly named final version.

A completed signature group did not move the record's status

Reference #: 260916.300.0508

A signature group configured to set a status when it completes did nothing, while the equivalent approval group worked, so the difference was easy to miss. This has been resolved so that completing a signature group writes the configured status onto the source record, records the change in the record's history and lets field update workflows react to it, exactly as a completed approval group does.

How will this affect users? Organizations whose signing routes are configured to move a record's status when a group completes will see that status change take effect.

Only one document in a signature package could be opened and signed

Reference #: 260916.300.0509

The signing screen could only ever open one document from a package, and on some packages the document it opened was a reference file that nobody is meant to sign. There is now a signing file picker listing the newest published version of each signable document, with reference material listed separately for download. Completion stamps every signed document rather than only one, and a document with no signature placements on it is left alone rather than being given a signed copy and a certificate for a signature nobody made.

How will this affect users? Signers working with packages that contain more than one document can reach and sign all of them, and the completed package contains a stamped copy of each.

Expired signing link notices repeated every night to the same recipient

Reference #: 260916.300.0510

The nightly notice telling a participant that their signing link had expired was itself renewing that link to the following day, so the same person expired again and was told again the next night, and every night after that. This has been resolved so that the notice no longer renews the expiry; first invitations and resends still set one, which is what stops an emailed link becoming a permanent credential. Participants already caught in the loop receive one final notice and then stop.

How will this affect users? Outstanding approvers and signers stop receiving repeated expiry notices, and administrators stop fielding complaints about them.

Participants could not be added to a signature or approval process from its console

Reference #: 260916.300.0511

The signature and approval console could replace and remove a participant but never add one, so a process started from a file on a record, which arrives with one group and nobody on it, could not be completed. An external signer, an employee or a company contact can now be added to any group, each subject to the system setting that allows that kind of participant, with the optional access PIN where it is enabled. Adding somebody to a group that is already running adds them without sending an invitation; use Resend on that group to send it. In the same area, participants who had been added by hand were labeled as having come from the copied template flow and, because of that label, refused to be removed; they are now identified correctly, carry no false badge and can be removed like any other participant.

How will this affect users? Anyone running a signature or approval process can complete its participant list, particularly on processes started from a document on a record.

Replacing a participant offered the wrong people and changed the participant's type

Reference #: 260916.300.0512

On the negotiation and signature console, Replace this participant offered a list of employees no matter what the participant was, and saving converted a vendor or client contact into an employee participant pointing at the wrong person, which then broke name resolution, access codes and email routing. The action now offers the right list for the participant being replaced: all employees for an employee, that company's own contacts for a vendor or client contact, or a typed name and address for an email-only participant, with the first candidate preselected and a search box on the list. The participant's type is never changed, a reason is required and is written to the record's audit trail, and any signature already captured for the person being replaced is cleared.

How will this affect users? Anyone replacing a participant on a document approval or signature process, and every organization with vendor or client contacts on those processes, gets the correct list of candidates and keeps the participant's type.

A signature process could start with a signer who had nothing to sign

Reference #: 260916.300.0513

When the documents on a pending signature package are re-chosen, any signature fields already placed on the removed version of a document were still counted toward the checks that decide whether the process may start. A process could therefore start even though a participant's only field pointed at a document version that had been replaced, and that person opened the package with nothing of theirs on it. The two start checks, that at least one field has been placed and that every signer has a field, now look only at the documents currently in the package. Earlier signature fields left behind by a document change are retained as history and are simply no longer counted, so the check can only ever block a process whose fields are unreachable, never refuse a sound one.

How will this affect users? Senders and the participants who receive their packages are no longer sent a package that cannot be acted on.

Previews, downloads and signature requests could use an unpublished version of a file

Reference #: 260916.300.0514

Actions on a package file were resolving the newest version by number rather than the published version, and the page labeled it Latest version. Preview, download, attach to the record and the signature panel now all act on the published version, and a file with no published version says so instead of offering a draft. Two situations were affected: a file that has no published version at all, and a file carrying a newer unpublished version on top of the published one.

When files are chosen for a signature process, each one is offered at its published version and a file that went through approval defaults to its approved version. Where a file has moved past its first version, that first version is offered as well, labeled original copy; it is never ticked for you and Select all leaves it out, so the original can be sent deliberately, alongside the approved copy or in place of it.

How will this affect users? Prevents an archived or unfinished draft being previewed, downloaded or sent for signature in place of the real document, while a sender who does want the original first version can still choose it.

Signature fields were placed on the wrong document, and did not land where they were clicked

Reference #: 260916.300.0515

On a signing request holding more than one document, the placement canvas ignored the file picker and always rendered the newest version across all files, so the picker could name one document while the pages shown, the text read for field suggestions and the position the fields were saved at all belonged to another. The canvas now renders the file and version that were chosen. Placement itself has also been corrected: clicking to place a field at an interface size other than 100% dropped it away from the cursor, and dragging a box moved it further than the pointer traveled, so that at 125% a field placed 400 pixels into the page landed 100 pixels below and to the right of the cursor, with the error growing toward the bottom right of the page. Both signature field screens, the one on a signing request and the one on a template or generated document, now convert the pointer position to page units before storing it. A ghost outline at the armed field's true size follows the pointer, the field drops centered on the click, and a freshly placed field can be dragged straight away.

How will this affect users? Fields land and move under the pointer, on the document that was selected, at any interface size. Switching to a large document also now shows a loading placeholder rather than a failure message while the pages are being prepared; measured on a 24 MB, 89 page document, that was about a minute of a message saying the file could not be rendered.

Signatures panel on a record showed an empty signer box for a document that had a signing flow

Reference #: 260916.300.0516

A document with a configured signature process showed an empty Choose a signer box on the record's Documents panel, which was indistinguishable from nothing having been set up, while the Approvals panel beside it listed its approvers correctly. This has been resolved so that the Signatures panel reads the signing flow the template supplied and shows it with a link to set the process up, shows the running request once it has started, and falls back to choosing a signer by hand only when the document genuinely has no signing flow.

How will this affect users? Users opening a record's Documents panel can see the signers a template configured rather than an empty picker.

An approval or signature link opened on the wrong account returned to the Home page with no message

Reference #: 260916.300.0517

An invitation to review, approve or sign is addressed to one specific account. Opening it while signed in on a different account was refused silently and returned the recipient to the Home page with no message, which was indistinguishable from a broken link. This has been resolved so that the recipient lands on a page stating the reason, naming the account the invitation belongs to where the two accounts provably belong to the same person, and offering a Sign out button so they can return on the right one. Withdrawn and expired invitations are explained in the same way.

How will this affect users? Approvers and signers who hold more than one user account are told what happened, and support staff receive fewer reports of broken links.

Documents that would not generate at all

Reference #: 260916.300.0518

Three conditions that stopped a document being produced have been corrected. A template naming a field on a table that is not part of the merge query stopped the whole document from generating, with a database error and nothing produced, for the sake of one field out of dozens; fields like that are now read on their own where the configuration allows it, and any that still cannot be resolved come through blank, which is what an unfilled field has always produced. Templates saved in the older Word format failed at the moment of generation with an unexplained error, and now produce a document that is handed back in that same format rather than being labeled as a newer one. A workbook containing a protected worksheet failed the entire merge and produced no document at all; worksheets are now merged one at a time, protection is lifted for the merge and put back where there is no password, and a password protected sheet is skipped so that the rest of the workbook still merges.

How will this affect users? Templates that reported an error and produced nothing now produce their document.

Content that silently went missing from generated documents

Reference #: 260916.300.0519

Several causes of missing text in a generated document have been corrected. In the section based document builder, a merge field typed with different capitalization than the field it refers to was left in the finished document as raw placeholder text even though the template checker reported the template as correct; those fields now match without regard to letter case, as they already did in the other template types. A sub-table block drawing on the same lookup table more than once, which is common, merged as nothing at all with no error shown; that block now merges as a complete table. Where a mergeable clause repeats once per selected related row, a clause library reference inside it now resolves for that row, so each repeat carries its own text instead of showing whatever the first row produced, and the resulting documents are far smaller: in our own testing one template went from a file Word could not open to one under two megabytes. A mergeable clause based on a related list now joins only through the relationship configured between that list and the document's own record type, rather than joining every other area that lists the same child, which either multiplied rows or referenced a column that did not exist and then failed the clause's placeholders.

How will this affect users? Documents that previously came out with blank sections or missing clause text now carry their content. A related list with no configured relationship to the record type will resolve record placeholders to nothing, which indicates a missing relationship in configuration.

Generated documents were stored and served as Word files, and values on PDF templates lost their formatting

Reference #: 260916.300.0520

A generated document was always recorded and served as a Word document whatever it actually was, so a PDF or spreadsheet output arrived labeled as a Word file and could open in the wrong application or refuse to open. The real output type is now recorded and served, including where a template is set to convert to PDF, and the same correction applies to document, template, package and clause downloads alike. Fields placed on a PDF template also used to merge as a raw value, showing an internal reference number instead of a linked record's name and leaving dates, currency and masked values unformatted; placed fields now go through the same resolution as fields in a Word template. A rich text field or clause placed in a spreadsheet cell used to land as raw markup and is now placed as plain text with its line breaks preserved.

How will this affect users? Anyone downloading a generated document, template, package or clause file receives it under its real type, and PDF and spreadsheet output shows dates, currencies, masks and linked record names as they appear everywhere else.

The document template picker ignored each template's own conditions

Reference #: 260916.300.0521

The template picker in a record's Documents area now applies the rules and conditions set on each template, so a template restricted to, for example, contracts over a certain value is offered only on records that qualify. Every active template for the record type used to be offered and the condition was ignored at the one moment it exists for. A condition that cannot be evaluated, for instance because it names a field that has since been deleted, leaves the template listed rather than silently removing it.

How will this affect users? Users generating documents see the templates that apply to the record in front of them, and administrators who restrict templates with conditions find those restrictions honored.

The Merge audit on a generated document was always empty

Reference #: 260916.300.0522

Generating a document now writes a merge trail listing each merged item and the value it produced, so the Merge audit on a generated document answers the question of why the document says what it says. It covers fields, sub-tables, clauses, static content and mergeable clauses, names each item the way version 22.7 did, and is written whether the document was generated from the record, by a bulk job or by a workflow. Documents produced by a mass signing job carry no trail, which matches version 22.7.

How will this affect users? Anyone reviewing or auditing a generated document can see exactly what was merged into it.

Mass process job rules written against a drop-down field matched no records

Reference #: 260916.300.0523

A rule written against a drop-down field, for example Vendor or Client Name equals a named company, compared the displayed name against the stored reference value and failed with a conversion error, so the job matched nothing. Rules on drop-down fields now compare against the displayed value as intended. Two further fields that jobs commonly filter on, the record identifier and the participant count, are offered in the field picker again. A rule group saved as ANY was also being displayed as ALL when the job was reopened, and saving the job again would silently have changed the rule, altering which records the job processes; the group now displays and saves the setting it actually holds. Finally, the results list repeated every generated document three times, so that a job producing twelve documents would show thirty six rows and repeat each line three times in its exports; each document now appears once, with its newest published version.

How will this affect users? Mass process jobs select the records they were written to select, a job's record selection can no longer be changed just by opening and saving it, and the results list matches what the job produced.

Generated, signed and quick-signed documents did not reach the record on cloud storage sites

Reference #: 260916.300.0524

On a site using cloud document storage, a document generated by a workflow was silently not filed on the record even where the template asked for it, a completed signed PDF did not return to the record it was signed for, and quick signing refused outright with a message saying that signing stored files was not supported. The check responsible has been removed from all three places, and each now stores the file on the record.

How will this affect users? Organizations that keep their documents in cloud storage receive generated documents, completed signatures and quick signed files on the record, as sites using local storage already did.

Change in Behavior: Everyone Reviews, Approves and Signs on the Signing Portal

Reference #: 260916.300.0525

Where a Signing Portal address is configured, every participant, employees included, now reviews, approves and signs on the Signing Portal. Following an emailed link, pressing Sign now or Review & approve on a record's Approvals or Signatures panel, acting from My Assignments, or using the header shortcut hands you to the portal already signed in, with no second sign-in and no PIN to enter. The record's Approvals panel becomes a status view, keeping the status rail, the certificate, package comments, reference files, the delegation note and the ability to start a process, while approving and rejecting, confirming each document, checking out, uploading a revision and delegating are all done on the portal. A Signing portal link is available on the record's Approvals and Signatures panels and on the process console for anyone who is a participant. Invitation emails are unchanged, and existing links, bell notifications and bookmarks still lead to the right place. Where no portal address is configured, staff continue to act on the in-application screens.

How will this affect users? Every approver and signer, including internal staff who previously acted inside Contract Insight, now completes the act on the Signing Portal.

Change in Behavior: Starting an Approval or Signature Process Now Has a Setup Step

Reference #: 260916.300.0526

Sending a document for approval or signature now creates the process first and starts it from a setup screen, rather than doing both in a single click. The setup screen is where the title, description, the people to be told and the routing choices are set, and it holds the package until documents are attached, at least one employee is listed to be told, groups exist and no group is empty, which are the same four checks version 22.7 applied before it would start a process. Starting is then a one-way step, and the settings that cannot change once people have been invited, such as the process name and the approval type, lock at that point and say so. Setup is a page of its own, with a trail back through the document to the record it belongs to, while the console remains the place to watch a process that is running; existing links open on whichever of the two applies.

How will this affect users? Anyone starting an approval or signature process now confirms its settings, participants and notification lists on a setup screen before it goes out, instead of accepting defaults.

Change in Behavior: Signature Fields Are Placed Before the Invitations Go Out

Reference #: 260916.300.0527

Creating an electronic signature process now carries straight on to setup, where participants, files and the reply-to address are chosen first, and the Signature fields step sits on the setup screen before the process is started. A process that signs on placed fields takes you to the fields screen with the document's published files already attached, and Start process and Cancel process are available on that screen, so the sequence reads create, place the fields, then start. The Signature layout action on a generated document stays disabled until a process exists that signs electronically on placed fields, and its tooltip names what has not been decided yet, whether that is no process, signing on paper, or signing anywhere on the document. A process set to sign only on placed fields will not start until at least one field has been placed and no field belongs to nobody, with a message on both screens saying what to do about it.

How will this affect users? Senders complete the layout before the invitations are sent, and a process that would have stranded a signer with nowhere to sign is stopped beforehand.

Change in Behavior: Mass Process Jobs Route Each Document to the Record's Own Participants

Reference #: 260916.300.0528

A mass process job now works out who signs from the record itself rather than from the signature flow set up on the template. An employee record is signed by that employee, a company record by its own contacts, and every other record type reaches its counterparty through the company assigned to the record, narrowed by the participant rules stored on the job. Each participant receives their own package on their own copy of the document, titled with the job title and the person's name, so nobody opens a copy carrying somebody else's signature. The run excludes deleted companies and inactive contacts, which is the same filter the participant count on the setup screen has always applied, and a record with no matching contact is still merged and reported as merged with nothing sent. Running a job a second time now asks for confirmation first, where previously a second run silently merged another document onto every matching record and emailed every signer again.

How will this affect users? Documents from a mass signature or acknowledgement job reach the counterparty contacts on each record, or the employee in the case of an employee job, instead of the internal signers named on the template.

Change in Behavior: Documents Are Locked While an Approval or Signature Process Is Running

Reference #: 260916.300.0529

While an approval or signature process is running on a generated document, that document is protected. The page shows a badge naming the process that is running and a banner explaining the way out, and it disables the name field and Save, the file and version drop zones, every file's settings, and the attach, check out and delete actions, each carrying its reason. Three further protections are now enforced on package files at all times: a file marked required cannot be deleted, a file checked out by another user cannot be deleted, replaced, attached or reconfigured, with check-in remaining the override, and a file with no published version cannot be previewed, downloaded or attached. Package, file and version deletion now asks for confirmation rather than committing on a single click.

How will this affect users? Document administrators can no longer alter a document that participants are actively approving or signing, or delete a required file or overwrite work another user has checked out.

Change in Behavior: Approval and Signature Steps Are Called Groups, and Placeholders Are Named for What They Do

Reference #: 260916.300.0530

A stage of an approval or signature routing plan is called a group throughout, on the generated document page, the setup screen, the process console, the record panels and the approval flow designer, which is the term version 22.7 used. Starting a process and managing one are no longer separate areas: the Approvals area and the Signatures area each carry their groups, participants, ordering and the start and runtime controls together, and participant lists show each person on their own line with their title, reason and required flag visible without opening an editor.

Two different things previously shared the word placeholder. The screens and actions for laying out where people sign are now called Signature fields, and the list of tokens that are pasted into a template's Word file is called Merge placeholders, which is also the wording now used on the template and clause administration screens. Nothing about the placeholders themselves, or about stored configuration, has changed.

How will this affect users? Everyone who sets up or runs document approvals and signatures sees the familiar wording, and administrators can tell the two placement screens apart by their names.

Change in Behavior: Every Signature Package Opens the Same Signing Screen

Reference #: 260916.300.0531

Older signature packages used to open a separate and slightly different signing screen from newer ones. Every package now opens the same signing experience, with wet signing, prefilled signatures, placed fields, adopting a signature, declining and delegation available throughout. Packages created before the newer screen was introduced are the ones that were opening the older kind.

How will this affect users? Signing an older package now works exactly like signing a new one, and administrators supporting packages created over several years have one screen to support.

Change in Behavior: Document Screens Use the Permissions Named After Them

Reference #: 260916.300.0532

The Merged Documents screen is now controlled by the Doc Collab: Prevent Access To Merged Docs permission, with System Administrators always allowed, rather than the document authoring templates permission it had been using; this corrects access in both directions, since people who had been given the prevent access permission were still getting in and people without template rights were being refused a screen they are entitled to see. The Negotiation Processes screen is now controlled by Manage Document Negotiations, and the Mergeable Clauses screen by Manage Document Authoring Mergeable Clauses, rather than both sharing the templates permission. Mass process jobs remain available to anyone who can manage document authoring templates, and the four shipped bulk process permissions are now honored as a second tier of control; in version 22.7 those four could be granted but were never read. A user holding none of the four is treated as unrestricted, so nobody loses access at upgrade.

How will this affect users? End users are not affected as only System Administrators have access to these settings. Administrators should expect the list of people who can reach these screens to change to match the permissions that were actually granted.

Change in Behavior: The Company Contacts Offered for Notification Are the Record's Own

Reference #: 260916.300.0533

The company contacts offered when setting up an approval or signature process are now limited to the contacts of the company assigned to the process's own record, and to contacts who are active, hold an email address and are marked to receive email. On a typical contract this reduces a system-wide list to the handful that belong to that vendor. Both screens that offer the list say so underneath the picker, and a record type with no company link falls back to the full list rather than showing an empty picker. A process can also no longer be started while a company contact participant is still unnamed; the setup screen blocks the start, and the Assign action, which offers the record's vendor contacts, is where the person is chosen. In version 22.7 a process could start with the contact unnamed, by which time the first group's invitations had already gone out.

How will this affect users? Anyone setting up a process picks from a much shorter and more relevant list; a contact who does not appear needs their receive email setting turned on.

Change in Behavior: Replacing a Participant Sends No Automatic Emails

Reference #: 260916.300.0534

When a participant on a signature or approval process is replaced, the row is rewritten and any signature already captured is cleared, as before. No removal notice is now sent to the person coming off and no automatic invitation is sent to the person coming on; whoever performs the replacement uses Resend on the process console to invite them. On a process set up to prefill signatures, the new person's slot is left empty and they type or draw their own signature, rather than finding one drawn in their name, which also removes the case where the previous person's name was left in the slot.

How will this affect users? Anyone replacing a participant mid-process should use Resend to invite the new person, and tell the person removed themselves.

Change in Behavior: New Approval Groups Accept Tracked Changes on Completion

Reference #: 260916.300.0535

When a new approval group is created, the option to accept the group's tracked changes when it completes is now ticked by default; previously it was unticked. Existing approval groups are unaffected and keep the value they were saved with, and editing an existing group still shows whatever that group was set to. Administrators who want the previous behavior on a new group can untick the option as they create it. Participants added in the approval flow designer are also locked by default again, matching version 22.7, and a Copy action on each group duplicates that approval group and every participant onto the end of the flow, carrying the locked and required settings; previously a copy dropped the required setting on every copied participant, so an approver who had to sign off silently became optional in the copy.

How will this affect users? End users are not affected as only System Administrators have access to these settings. Administrators creating new approval groups should be aware that tracked changes will be accepted on completion unless the option is unticked.

Change in Behavior: Generating a Document Stops to Ask Which Related Rows a Clause Should Use

Reference #: 260916.300.0536

If the document being generated includes a related list clause whose rows have never been chosen, Generate and Generate & Save now open that clause's row chooser instead of merging, then resume the generate once the question is answered, walking each unanswered clause in turn. Previously the clause quietly merged as its empty message and the expected text did not appear in the finished document. A deliberate answer, including choosing nothing at all, is remembered and never asked again, and Cancel abandons the generate.

How will this affect users? Anyone generating documents from templates carrying related list clauses is asked the question once, rather than discovering the omission in the finished document.

Files in an approval or signature package were ordered by their protection setting

Reference #: 260916.300.0540

When files are attached to a signature or approval package, each file's position in the package is now taken from the Position in the document setting on the document's own file list. Previously the position was written from the file's Protection setting instead, so every file sharing a protection setting was recorded at the same position and the package's order followed protection rather than the order the author arranged. A set assembled as cover letter, then agreement, then exhibits could therefore reach the recipient in another order, and there was no way to correct it from the document. Packages assembled before the upgrade keep the order they were recorded with, because changing that would alter what a completed process is recorded as having contained.

How will this affect users? Approvers and signers open the files of a package in the order the author arranged them, and the person assembling a package can rely on the position they set on each file.

Every File on a Template Is Generated Into the Finished Document

Reference #: 260916.300.0541

A document template can hold more than one file, for example a cover letter, the agreement and its exhibits. Unless the template is set to append its Word files into one document, each file is merged in its own right and the finished document holds all of them, in the order set by each file's position on the template. This applies whether the document is generated from a record's Documents area, by a workflow or by a mass process job. The template's own content, its fields, clauses, static content and sub-tables, is resolved once for the whole set rather than once for every file, so the time a generate takes does not climb with the number of files on the template. A file that has nothing to merge, for instance one with no file uploaded against it, is left out and the rest of the set still comes through.

How will this affect users? Users generating from a template that holds several files receive every one of those files on the finished document, ready to be reviewed, sent for approval or signature and attached to the record.

Module: E-Sourcing & Solicitation Management

Employee and department assignments on a solicitation could not be viewed or changed

Reference #: 260916.400.0500

A solicitation had no assignment section, so employees and departments assigned to a solicitation could not be seen, changed or removed, and assignments recorded before the upgrade were unreachable. This has been resolved so solicitations carry the same assignment panel that contracts and requests do, named Assigned Employees and Departments on a solicitation, subject to update permission and hidden while the record is on legal hold. The upgrade adds the panel to the Notes tab of each solicitation layout, so it is in place without any configuration on your part.

How will this affect users? E-sourcing users can assign staff and departments to a solicitation and see the assignments that already exist.

Solicitation questions and answers displayed their formatting markup instead of formatted text

Reference #: 260916.400.0501

Question and answer text on a solicitation has always been written with a rich text editor, but the two fields were treated as plain text, so their markup appeared on screen instead of the formatted text. This has been resolved so both are rich text fields, edited with the full editor and displayed as formatted text. Anywhere a rich text field appears in a list, a sub-grid, an export, a record PDF or quick search, it now shows its readable text rather than its tags, and linked record panels can format their columns, so dates and amounts in those panels read the way they do elsewhere. The field setting is applied to your configuration during the upgrade and no stored content is altered.

How will this affect users? Anyone reading or writing solicitation questions and answers, and anyone exporting records that carry rich text fields, sees readable text.

Apostrophes were silently removed from a solicitation question

Reference #: 260916.400.0502

A question typed into the Questions and Answers area of a solicitation came back with every apostrophe removed, so "Can't the bidder's bond be posted late?" was stored as "Cant the bidders bond be posted late?". No message was shown; the text was simply different from what had been typed, and a question made up entirely of apostrophes saved nothing at all and reported nothing. This has been resolved so a question is stored exactly as it was typed. Questions saved before the upgrade keep the text they were stored with.

How will this affect users? Buyers and vendors using solicitation questions and answers will see their question stored as written.

Amendment notices for open solicitations were not being sent

Reference #: 260916.400.0503

Registered respondents were not being told when an open solicitation was amended, because the scheduled job that sends the notice was not running. This has been resolved so the notices go out again. For an invitation-only or public solicitation that is currently open, registered respondents' contacts receive the authenticated Gateway link, and for a public solicitation every vendor whose product and service codes overlap and who has not already responded receives the public link. Each amendment is stamped once it has been announced, so a later run cannot e-mail the same amendment twice.

How will this affect users? Solicitation managers can rely on amendments reaching their bidders again.

Bid alert digests were not reaching subscribers

Reference #: 260916.400.0504

Subscriptions, their daily and weekly frequencies and the Gateway address configuration were all in place, but nothing was sending the digests, so subscribers stopped hearing about new opportunities. This has been resolved so subscribers again receive their daily or weekly digest of matching opportunities, in the same layout as before: a View All Bids button at the top and the bottom, then one block per opportunity showing the title, the matched product and service codes, the matched keywords and the date posted, with links that open the solicitation in the Vendor/Client Collaboration Gateway and a working unsubscribe link. The bid alert interval on the Scheduled Jobs screen controls how often the check runs, and a subscriber who has already been sent a digest that day is skipped, so a short interval cannot produce repeated copies of the same digest.

How will this affect users? Bid alert subscribers receive their digests again, and administrators can set the timing on the Scheduled Jobs screen.

The Type column on the Solicitations list was blank on nearly every solicitation

Reference #: 260916.400.0100

The Type column on the Solicitations list, and in exports taken from that list, was read from an old five entry list of type names that solicitation types have never actually been stored in, so it was blank on nearly every solicitation. This has been resolved so the column is read from the record types your administrators maintain for solicitations, and shows the type held on the record, such as RFP, RFI, RFQ or Sole Source. The change is applied to your configuration during the upgrade and no stored data is altered.

Two limits are deliberate. A solicitation whose stored type belongs to another area, a contract type or a request type for example, is shown blank rather than borrowing that other area's name. A small number of older solicitations that had been showing a type name by coincidence, because the old list numbered its five entries the same way, now show blank as well. In both cases the type held on the record is not a solicitation type, and the record is worth correcting.

How will this affect users? Anyone working from the Solicitations list, or sorting, filtering or exporting it by type, sees the solicitation's type. System Administrators may find a small number of solicitations whose type needs to be set.

Module: Purchase Order & Procurement Management

A purchase order created from a shopping cart opened a different order

Reference #: 260916.410.0500

After creating a purchase order from a shopping cart or from a request, the application opened whichever purchase order was newest in the system rather than the one that had just been created, so two people checking out at the same moment could each be taken to the other's order. This has been resolved so checkout always opens the order that was created for you.

How will this affect users? Anyone creating purchase orders from a cart or a request lands on their own order, which matters most on busy systems.

The total on a request shopping cart was always blank

Reference #: 260916.410.0501

The footer total on a request shopping cart never showed a figure. The request cart asked the database for its total in a way that could not succeed, and because the failure was not reported, nothing was shown to the user and the total simply stayed blank. This has been resolved so a request cart shows its total. The purchase order cart was already correct.

How will this affect users? Anyone building a request through the shopping cart can see what the request comes to before submitting it.

The Line Item Type setting had no effect on purchase orders and requests

Reference #: 260916.410.0502

The Line Item Type for PO and Request setting decides whether a line item is typed free hand, chosen from the items list, or added through the shopping cart, but the setting was not being read, so every user got the generic form regardless of what had been configured. This has been resolved so the setting is honored on both purchase orders and requests. With the setting on an items based mode, New on a line items grid opens the shopping screen for that purchase order.

How will this affect users? Organizations that configure how purchase order and request line items are added will see their choice applied.

Supplier and employee pickers in procurement either listed everything or stopped short

Reference #: 260916.410.0503

The supplier catalog chooser on the shopping screen drew every supplier into one plain list, so on a site with a long supplier list it took seconds to open, if it opened at all. The catalog access picker had the opposite problem: it listed only the first five hundred employees alphabetically in a plain drop-down with no search, and nothing on screen said a limit had been applied, so on any site with more than five hundred active employees the people past the five hundredth name could not be granted access at all and appeared not to exist. This has been resolved so both pickers filter as you type, search the whole list and load only the rows you can see.

How will this affect users? Buyers choosing a supplier catalog and administrators granting catalog access can reach every supplier and every employee, on systems of any size.

The Reason column on the asset shrinkage summary showed the source department

Reference #: 260916.410.0504

On the asset shrinkage summary the column headed Reason actually showed the source department, and the write-off reason was not displayed anywhere on the screen. This has been resolved so the summary groups by both the write-off reason, such as Damaged, Consumed or Expired, and the source department, with the two columns labeled accordingly. The split rows add up to the same totals as before.

How will this affect users? Anyone reviewing asset shrinkage can see why stock was written off as well as where it came from.

Link Contract on a purchase order required System Administrator rights

Reference #: 260916.410.0505

The Link Contract action on a purchase order was available only to users carrying the System Administrator flag. This has been resolved so it is available to anyone with update rights on the record, as it was in version 22.7. The Purchase Order module license check still applies.

How will this affect users? Buyers with update rights on a purchase order can link it to a contract without administrator rights.

Receiving could be blocked without explanation when the purchase order screen setting was typed by hand

Reference #: 260916.410.0506

The setting that selects the classic purchase order screen was honored only when it held the exact lowercase word "true". A value entered any other way, such as True, Yes or 1, silently switched the site to the other purchase order screen, which requires an order to be marked Order Placed before anything can be received against it. This has been resolved so the setting is read as a true or false value and all of those spellings mean the same thing; a value saved from the settings screen behaves exactly as before. On sites using the classic purchase order screen, receiving is available on the strength of your update permission alone. On the other screen, Order Placed must be set to Yes, a value of n/a does not satisfy it, and the message on the disabled action now names that field so it can be found. Order Placed is an ordinary field a user sets by hand.

How will this affect users? Buyers get a clear reason when receiving is unavailable. System Administrators of sites whose purchase order setting was edited by hand should confirm which screen the site is using after the upgrade.

Module: Vendor/Client Collaboration Gateway

Switching the Gateway to sign in by e-mail address could lock contacts out

Reference #: 260916.420.0500

The Gateway's Simplified sign-in matches a contact on their e-mail address, so switching to it while two contacts share a user name locks those contacts out. One screen checked for that and offered a fix; the single sign-on screen wrote the same setting with no check at all. The sign-in method was also a free text box in which any typed value could be saved. This has been resolved so the setting offers only its two valid choices, Standard and Simplified, and the duplicate check applies wherever the setting is changed. Before the change is saved, the Sign-in tab lists any contacts who share a user name: who they are, the company they belong to, the name they sign in with today, the name they would be given and whether they will be e-mailed. The save is refused until the clash is resolved, and the screen carries the action that renames the duplicates and e-mails each affected person their new name. The setting change is applied to your configuration during the upgrade and no stored data is altered.

How will this affect users? System Administrators changing the Gateway login method are warned first, and the vendor contacts who would have been locked out keep their access.

A request raised through the Gateway did not tell the contact who raised it

Reference #: 260916.420.0501

When a request was raised by an outside contact through the Vendor/Client Collaboration Gateway, the status notification went to internal recipients only, so the contact who raised the request was not told when it was accepted or rejected. This has been resolved so that contact receives the same notification, with a link into the Gateway rather than into Contract Insight, because they have no account there. Internal recipients and the requestor continue to receive their copy unchanged.

How will this affect users? Outside contacts who raise requests through the Gateway are told what happened to them, which reduces the follow-up calls to your staff.

A record type could hold more than one default request type

Reference #: 260916.420.0502

Setting a default request type marked the chosen row as the default without clearing the previous one, so a record type could accumulate several defaults and the screen showed whichever was returned first. This has been resolved so choosing a default clears the others for that record type first, and clearing the choice leaves none. Record types that already carry more than one default are left as they are until someone saves that record type, which then tidies it.

How will this affect users? End users are not affected as only System Administrators have access to this setting.

Gateway item approvals were recorded against the wrong contact

Reference #: 260916.420.0503

The history entry written when items submitted through the Gateway were approved named whichever contact happened to share a number with the approving employee, rather than the contact the notification was sent to. This has been resolved so the entry names the contact who was e-mailed, with the acting employee recorded as the actor. Entries written before the upgrade are left as they are.

How will this affect users? Anyone auditing Gateway item approvals can see who was actually notified.

Connector: Single Sign-On (SSO) Authentication

Failed single sign-on attempt returned to the identity provider in a loop without showing an error

Reference #: 260916.500.0500

When a single sign-on attempt could not be completed, the user was handed straight back to the identity provider and the reason was discarded, so the attempt repeated without anything being shown on screen. This has been resolved so a failed attempt lands on a dedicated sign-on problem page. A rejected sign-in shows a general message; an unexpected failure shows a reference number that support can match to the system's own error log; and an attempt blocked because the connector is not licensed says so. Where the standard login address is open, the page offers it. Identity providers still configured with the older sign-on failure address are forwarded to the new page automatically.

How will this affect users? A user whose single sign-on fails sees a message explaining that it failed, with something concrete to give their administrator, instead of an attempt that appears to repeat forever.

Just In Time provisioning failed for every user when a mapping named a field that does not exist

Reference #: 260916.500.0501

If just in time provisioning was configured with a mapping to an employee field that is not present on the system, the statement it built was invalid and provisioning failed for every user, which defeated the very check that was meant to make a mapping for a missing field harmless. This has been resolved so a mapping for a field that does not exist is dropped cleanly, the remaining mapped fields are written as normal, and a definition left with no valid fields is skipped rather than attempted.

How will this affect users? Organizations that create or update accounts automatically at sign in are no longer exposed to a single unusable mapping stopping provisioning for everyone.

Attribute changes sent by the identity provider did not reach people who already had an account

Reference #: 260916.500.0502

Just in time provisioning updates were silently skipped for anyone who already had an active account, so a name, department, title or any other mapped attribute changed at the identity provider never took effect on a normal sign in; only newly created accounts ever received the mapped values. This has been resolved so the update pass applies to existing active accounts as well, and the provisioning trace records the statement that ran and the reason a rule did not match.

How will this affect users? Organizations that maintain user records from their identity provider will see attribute changes carried into Contract Insight at the person's next sign in.

Connector: External E-Sign Integrations

Custom DocuSign envelope fields could not be configured and were never sent with the envelope

Reference #: 260916.510.0500

The screen for mapping custom envelope fields could not be reached from the DocuSign settings screen, and no part of the application read the custom field mappings, so any mapping an organization had configured was silently ignored when an envelope was sent. This has been resolved so a working mapping screen is linked from the DocuSign settings screen, and the mapped values are resolved from the record and applied to the envelope, honoring the Add or update, Add only or Update only choice set on each mapping. Mappings already configured are used as they stand, and mappings can be set for contracts, requests, vendors and customers, employees, purchase orders and solicitations.

How will this affect users? Organizations sending envelopes through DocuSign get their custom envelope fields populated again, and administrators can maintain the mappings.

Recipient roles chosen for a signNow send were ignored and everyone was sent as a signer

Reference #: 260916.510.0501

The role chosen on the Recipients step of a signNow send was not sent to signNow, so every recipient was created as a signer regardless of what the send screen showed. This has been resolved so the Signer, Viewer and Receives a Copy roles are sent through, the role list appears for signNow as it already did for DocuSign and Adobe Acrobat Sign, and the chosen roles are repeated on the review step before the send goes out.

How will this affect users? Anyone sending documents through signNow gets the recipient roles they selected, so people intended to receive a copy are no longer asked to sign.

Adobe Acrobat Sign sends did not carry roles, copied recipients, reminders or an expiration

Reference #: 260916.510.0502

An Adobe Acrobat Sign send ignored the recipient role, the copied recipients, the reminder frequency and the expiration date set on the send form; every recipient was sent as a signer and the other three settings were dropped. This has been resolved so the Signer and Approver roles are honored, copied recipients are passed through, and the reminder frequency and expiration date set on the form are applied to the agreement. The reminder frequency list offers all three options, including every other day. These values start blank on every Adobe Acrobat Sign send, because there is no stored account default for them.

How will this affect users? Anyone sending documents through Adobe Acrobat Sign gets the roles, copied recipients, reminders and expiration they set on the send form.

signNow could not be selected until someone else had connected, and sends went out under another person's authorization

Reference #: 260916.510.0503

signNow is a per employee connection, and three things did not reflect that. The signNow option appeared on the send screen only after somebody had already connected an account, so the first person at an organization had no way in. A send then used whichever signNow authorization happened to be stored rather than the sending employee's own. And an employee whose connection had expired or been revoked had no route to reconnect. This has been resolved so signNow appears as soon as an administrator has registered the signNow keys, a send uses the sending employee's own authorization, and an employee who has never connected, or whose connection is no longer valid, is offered an Authorize signNow link that takes them through the connection and returns them to the send they had started.

How will this affect users? Every employee who sends through signNow connects their own account when they need it, and documents go out under the correct sender.

Signature requests canceled or deleted at the provider still counted as out for signature

Reference #: 260916.510.0504

Each signing service reports its outcomes in its own words, and requests a service had reported as deleted or aborted were counted and colored as though they were still in flight, with the signature status list, the marker on a record and the Home card able to disagree with one another. This has been resolved so every wording a signing service can return is interpreted in one place and every screen agrees on whether a request is still out, finished or canceled. A status that is not recognized is treated as still open and shown as the service wrote it, so a new word from a service can never make a live request disappear from a list.

How will this affect users? Anyone tracking documents sent out for signature sees accurate counts and colors, and canceled requests no longer appear to be waiting on someone.

Connector: Data Feed and Document Services

Updated federal clauses were never downloaded, and change notices reached only one subscriber

Reference #: 260916.520.0500

The scheduled job that pulls updated FAR, DFARS and NFS clauses asked the government feed for everything changed since the current date and time, which could only ever match a change dated in the future, so in practice it returned nothing and clause libraries never moved. Separately, when a watched clause did change, only one person on the subscriber list, whoever happened to be read last, was emailed, and the subject line produced garbled text. This has been resolved so the job asks from its own last run date, with a job that has never run establishing its baseline on the first run rather than pulling a very large backdated set, and updated clauses are applied both to the clause library and to the document authoring clause library. Every subscriber now receives their own message addressed to them, the subject reads as intended, for example FAR clause 52.219-1 has been updated, and the body names the clause, its title and the date the agency published the change. Notices are sent by the nightly job and by a manual refresh from the clause administration screen. No configuration change is needed.

How will this affect users? Organizations monitoring federal clause libraries receive clause updates and the notices that go with them, most of which were not being sent at all.

SAM.gov monitoring added a duplicate exclusion record on every run and skipped exclusion checks

Reference #: 260916.520.0501

Each time the scheduled SAM.gov job ran and found the same unresolved exclusion for a vendor, it added another copy of that exclusion instead of updating the one already on file, so a vendor's compliance detail grew by one row on every run indefinitely. Several values, including the SAM.gov identifier, the DUNS identifier and the postal code, were also being written into the wrong columns. Where the entity search returned no results for a vendor, that vendor's exclusion check was skipped as well, even though the two are unrelated. And where SAM.gov itself returned an error, the job continued and logged a misleading internal message rather than the real failure, inflating its own error count in the process. This has been resolved so an existing exclusion is matched and updated in place, each value is written to the column it belongs to, the entity check and the exclusion check run independently, and a SAM.gov failure is reported as what it is. Notification links in screening emails now open the company record in Contract Insight.

How will this affect users? Organizations screening suppliers against SAM.gov get complete exclusion results and compliance detail that stays clean; duplicate rows created by earlier runs will stop multiplying.

Adding a company from a SAM.gov match did not fill the SAM.gov identifier or CAGE code

Reference #: 260916.520.0502

Choosing a match in the SAM.gov lookup while adding a company filled the legal name and address but left the company's SAM.gov identifier and CAGE code empty, because those two fields are shipped locked so that only the feed writes them and the lock was causing the incoming values to be discarded. This has been resolved so both are filled from the match and shown read only, as they were before, which also gives the exclusion monitoring that runs after a company is added the identifiers it needs. Whether the two fields appear on the screen at all still depends on the field set configured for that company record type.

How will this affect users? Anyone adding vendors or customers with the SAM.gov lookup gets the identifiers with the match, and monitoring for that company works from the moment it is created.

Google Drive subfolders and Google documents not visible, and exported files arriving in the wrong format

Reference #: 260916.520.0503

Several faults made Google Drive import unreliable. Subfolders could not be opened below the first level; Google Docs and Sheets appeared only at the top of the drive and vanished once filed into a folder; the export format was chosen by looking for words in the file name, so a document with pdf in its title came back in the wrong format; an exported Google document arrived with no file extension and so would not open; and folder placement in the tree was inaccurate. This has been resolved against Google's current interface, so folders open at every depth, Google documents appear wherever they are filed, the file's real type decides the export format, and the correct extension is added. Browsing is also noticeably quicker, because only the folder you open is listed and the sign-in is refreshed only when it is close to expiring rather than before every request. A Google account already linked continues to work and nothing about the stored connection changes. Archives and video remain excluded from the picker, the four export formats are unchanged, and copying a document back out keeps Google Drive's own naming behavior.

How will this affect users? Anyone importing from Google Drive can reach documents at any depth and in any format; workarounds such as keeping documents in the top of the drive are no longer necessary.

OneDrive connection could not be completed after signing in

Reference #: 260916.520.0504

Connecting a OneDrive account signed the user in and obtained their consent, then failed with a message saying you had been signed in but the connection could not be completed, because one field in the provider's reply was read as text where the current Microsoft service returns it as a number. This has been resolved so both cloud drive connections accept either form and the connection completes. A failed connection also no longer shows the same message whatever the cause: a refusal by Google or Microsoft shows that provider's own error text, which is the only thing an administrator can act on; a reply carrying neither an authorization nor an error is recorded in full; and a failure exchanging the authorization says so and points at the log.

How will this affect users? Users connecting a OneDrive account can complete the connection, and administrators troubleshooting a failed one are given the provider's actual reason.

An employee screening result could be written over a compliance record of a different kind

Reference #: 260916.520.0101

When the scheduled screening job checked whether an employee already held a compliance record, it did not take the kind of compliance record into account, unlike the equivalent check for companies, so a new result could be matched to a record of a different kind and written over it. This has been resolved so the check includes the kind of record and each result updates the one it belongs to. A duplicated entry in the screening log, which recorded the outgoing request a second time in place of the reply, is corrected at the same time.

How will this affect users? Organizations that screen their own employees against sanctions lists keep a complete screening history for each person, with no result landing on top of another.