What's New in Syniti Solutions 7.5.0

Release Date: 4/19/22

This release contains:

Product Certification

Refer to the Product Certification Matrix for the versions of third-party products that this release has been certified against.


The SAP transports for Stewardship Tier installations are now split into 2 packages and are documented separately.

  • Core—contains the functions and programs required by Stewardship Tier to extract data via RFC and load via BDC. These transports are distributed with the Stewardship Tier installation in versions 7.4.8 and later.

  • Supplementary—miscellaneous functions, programs, and utilities for supporting SAP-based projects. Contact Syniti Support and raise a support ticket to get this transport.

The code in the Core transports has been modernized to adhere to latest ABAP coding standards. Both the Core and Supplementary transports are compatible with SAP installations of EHP 7 FOR SAP ERP 6.0 [SAP_APPL 617] (based on SAP NETWEAVER 740 [SAP_BASIS 740]) or higher.

NOTE: Customers using older versions of SAP can contact Syniti Support who will assist in locating versions of the required programs and functions that are compatible with their SAP Instance.

Refer to Support Article SAP Transports for 7.4.8 and Above for SAP Transports available when running version 7.4.8.


NOTE: If psaCollate is installed on the instance you are upgrading, you must uninstall it before upgrading to this version. The collation technology is included in the product in 7.4.5 and later. To uninstall psaCollate refer to the Knowledge Base article psaCollate Incompatible with SST 7.4.5+.

NOTE: When upgrading to Stewardship Tier 7.4.5 AND LATER, data sources are automatically assigned with the Collation Type of General Latin Case-insensitive. This ensures that the ADM AutoGen continues to create SQL tables whose text columns have a case-insensitive collation.

NOTE: When upgrading to Stewardship Tier 7.4.6 AND LATER, open a support ticket with Syniti Support to request a new license in order to use Entity Validation and Migration Reports. If using Entity Validation, you must also request a Melissa license.

NOTE: A new, critical step has been added to the Post Upgrade section of the Installation process. After an upgrade to Stewardship Tier, users must re-create their BAPI templates. Failing to do so will cause the posting of a BAPI template to fail. Refer to Re-create BAPI Templates in the Install Manual for more information.

NOTE IF YOU ARE UPGRADING FROM 7.0.6 OR BELOW: You may need to migrate your security settings to use centralized security. Users of Data Quality (formerly dspMonitor), Master Data Management (formerly dspConduct), and Mass Maintenance (formerly dspCompose) must update security roles when upgrading to this version. Refer to the Syniti Solutions Centralized Security Migration Manual for important information about using security in the Stewardship Tier in this version and later. Consult this manual BEFORE updating to this version, as an analysis of current security assignments must be completed before the Stewardship Tier can be updated.

NOTE IF YOU ARE UPGRADING TO 7.4.2 OR HIGHER: Please be aware that any JavaScript content added is stripped away and any remaining, safe HTML is displayed to users. In Stewardship Tier versions 7.4.1 and earlier, users were permitted to enter HTML and have it rendered in the UI or included in file downloads from the UI. There were no restrictions in place on what HTML/JavaScript text was permitted, leading to potentially dangerous cross-site scripting attacks. Refer to the Knowledge base article Unsafe HTML/JavaScript removed in Stewardship Tier 7.4.2 for more information.

WARNING: Customizations made to any component of the delivered Syniti Solutions will be overwritten in the next upgrade. To preserve customizations, make a copy of the customizations prior to applying any upgrade.

A customization is a change to the underlying source code, which differs from configuration – normal setup of the software, such as setting up workflows and defining parameters via the configuration pages.


Stewardship Tier


The following security definitions and associated keys have been created to further define security rights in Assemble:

  • Assemble.DataSources—limits users to creating packages with the specified data sources as targets.

  • Assemble.WorkingDataSources—allows users to create packages with all working (non-delivered application) data sources.

  • Assemble.ApplicationDataSources—displays delivered application data sources. Packages that read from or write to tables in the delivered databases are not standard nor recommended and can cause functional issues. This key allows Power Users to access existing packages created with delivered application data sources.

NOTE: If a security role exists and has an Assemble WebApp group assigned, the Assemble.WorkingDataSources security key is assigned by default in a post-install step. The other two keys must be configured by administrators, depending on what database access the user needs. Refer to Set Up Security for Assemble for more information.


In order to accommodate users' ability to provide a variety of information related to the review/approval Package Groups, the following field names were updated:

Master Data Management

  • Messages sent along with MDM workflows are now logged for analysis later. The logs can be accessed in Common on the Vertical View of Debug Log page. Refer to View Workflow Messages for more information.

  • Shared mailboxes can now be used to receive request-based email notifications. Administrators can register mailboxes and then assign the mailbox to one or more positions. If a new request is created or a subsequent request role to which the position has access becomes ready, then an email is sent to the mailbox address. Refer to Set up a Mailbox for Position-Based Workflow Notifications for more information.

  • Using position-based assignment, users and administrators can quickly set how users receive workflow notifications for request events, such as when a request is ready for review or when a request is late. Users receive the notifications based on the positions they have access to through their request roles. Users can select to receive notifications through email, popup, or both. Users can also choose to receive no notifications. Refer to Set User Workflow Receipt Preferences by Position for more information.

  • Users can update the workflow receipt preferences for multiple positions for multiple users either manually or through Excel integration on the new All User Positions page. Refer to Edit Workflow Receipt Preferences in Bulk for more information.
  • A role owner can now be assigned easily to a request role, either directly on the Request Role page, or using API procedures delivered with MDM. Role owners receive notifications when a request they own is canceled, deleted, posted, posted with errors, rejected, reset, and finished. Role owners also receive all SLA notifications. Refer to Add Role Owners for more information.
  • A user who finishes a request role is set as the role owner automatically. Owners receive email workflow notifications about request events during request processing. Refer to Set Workflow Notification by Position for more information.

  • Users can update the workflow receipt preferences for multiple positions for multiple users either manually or through Excel integration on the new All User Positions page. Refer to Edit Workflow Receipt Preferences in Bulk for more information.

  • Users can now view all users assigned to a request role on the Request Role Users page, and send a user an email from that page notifying them that a request is ready to be worked on. Refer to View a Request’s Roles, Tasks and Users and Send Ad Hoc Notifications to Request Role Users of Request Readiness for more information.

  • Users can now use views to create custom Audit reports to generate the audit details, and can use this custom report instead of the delivered Audit report. These reports are sent in the notification email as an Excel spreadsheet attachment, and they provide more opportunities to show drop down values, and other validation features. Refer to Assign a Custom Audit Report for more information.

  • Users can add two columns, one containing the role owner and the other the SLA minutes late for the request roles, to the Requests page in the Content WebApp using an API view included with the Stewardship Tier. Include the view apiRequestAllOwnersMinutesLateSel.sql using an outer join in the Content WebApp’s Request page view to show Minutes Late and Role Owner for each request.

  • Auto Post and Auto Finish roles no longer receive Role Ready or Reset/Reject workflow notifications when preceding roles are reset or rejected.

  • Added another level of escalation for SLAs at the category level with SLA Late Cycles, which are the number of cycles a request can be late before escalation notifications are sent. The SLA Late Cycles value ranges from 1 to N, where the number indicates how many multiples of the role's SLA level pass before an Escalation notification is sent.

    For example, a role with an SLA of 1 day and 6 hours in a category where this SLA Late Cycles value is set to 5 would result in SLA notifications being sent:

    • At 1 day and 6 hours for the Late SLA notification

    • At 5 days and 30 hours for the Escalation notification

    If this value is 1, the Late SLA notification and the Escalation notification are sent at the same time.

    All users assigned to the role that have the workflow notification settings set for ESCALATION on the My Settings and User Settings pages are notified on the escalation date.

Resolved Issues

Stewardship Tier


Fixed an issue with the way Pass Through tables worked. A rule runs to set all data in a Pass Through table to ignore the Sync action. However, this rule did not work correctly for Not in Host records, causing values that only existed on the Destination system to be marked for deletion. The rule now works as expected where Not In Host records in Pass Through tables on the Destination system are no longer marked for deletion. Users still need to use caution with Pass Through tables because child records of Not In Host records can still be marked for deletion. [DSP70-1548]

Master Data Management

  • Fixed an issue where a non-key Column was selected as “Include in Record Key” that caused the Audit Details import to fail. With the fix, for new record creations and deletions, the field marked as “Include in Record Key” displays as part of the concatenated key. Also, for changes, due to the way the #AuditColumn table stores the updated data, the value for a non-key field is only available if that field is changed. [DSP70-1745]

  • Fixed an issue that occurred when a user clicked the Validate or Finish button for a role from the Request Role page. The validation message that displayed had the incorrect role name in the title bar. This role name was always the first role name in the request by priority order, instead of the role name that validated or finished the role. With the fix, the validation message displays the name of the role that validated or finished the role in the title bar. [DSP70-1754]

  • Fixed an issue related to auditing data that was imported into MDM using Excel integration. If a user enabled auditing for a category, created and submitted a new request, and designed the content page to use Excel integration, any records imported using this method did not display on the Review Role Audit Details page as they should have. With this fix, records added using Excel integration are tracked for auditing as expected. [DSP70-948]

Changes in Previous Versions

Previous Versions of Help

Help Build Date:June 08, 2022 11:57:40 AM