Welcome to the Syniti Ideas Portal!

Do you have feedback regarding the current product, or new ideas for improvement?

Tell us how we can make the Syniti Knowledge Platform more useful to you.

Security Profiles for Business Processes

At Eli Lilly, there is a desire to control data access (via Security Profiles) at the Business Process level. The Data Quality hierarchy has 4 levels: 1 - Subject Areas > 2 - Business Process > 3 - Datasets > 4 - Rules However, Security Profiles are only available on levels 1 and 4. For Eli Lilly, level 1 is less granular than they would like and level 4 is far too granular. The ideal would be for them to set a Security Profile on each Business Process. NOTE: Consider that each Security Profile must be multiplied by the number of Security Roles (https://ideas.syniti.com/p/skp-security-divorce-profiles-from-roles). In practice, nobody can set meaningful Security Profiles more granular than the Subject Area level until they are divorced from Security Roles.

Ben Bauer 14 days ago

1

Use-cases for multiple Report Cache Datastores

Currently, it is only possible to specify a single datastore for writing the output of DQ reports in SKPv2. This single datastore is configured here: https://knowledge.syniti.com/admin/parameters/data-quality At Eli Lilly, and I’m sure other clients would agree, it would be wonderful to be able to register any number of report cache datastores. Then, the specific datastore to use could be specified when toggling the ‘Save Errors’ option in the Implementation asset. Use-cases: Client has multiple tiers of report data (DEV > QA > PROD, for example) and they wish to register 3 reports (aka Enforcement + Implementation) under each Rule and have their output written to 3 separate database instances. Client has multiple Subject Areas and they wish to have their output written to a separate database for each Subject Area.

Ben Bauer 15 days ago

2

SKP Security - Divorce Profiles from Roles

Please link Profiles only to User Groups, not to Roles. The link from a Security Profile to a Security Role is enforced in a subtractive way that is very confusing and tedious to work around. The tagging of objects with Security Profiles should not require Role configuration, and those Roles certainly shouldn’t override a User’s other Roles. Hypothetical: If my User is a member of both a Read-Only Role and an Admin Role, but the Read-Only Role is linked to a Security Profile, then I can no longer maintain any objects tagged with that Security Profile. If I then add the Admin Role to the Security Profile, then I now have to give Admin permission to any user that is to be able to see the objects tagged with that Security Profile. Workaround is to create 2 Read-Only Roles and 2 Admin Roles, one set with the Security Profile and one set without it. Real Example: We have identified 19 different "Security Roles" at Eli Lilly (so far). These represent personas who have different page-level permissions throughout SKP. And we have identified 4 different "Security Profiles" at Eli Lilly (so far). These represent data-level permissions for their 4 subject areas (or so we thought). What we thought would be a security configuration of 19+4=23 roles, is now going to be 19*4=76 roles!

Ben Bauer about 1 month ago

2

Add 'Target' as a column in Migrate > Deployment Reports

We have multiple targets in a given dataset. See the screenshot below to view how the reports are organized by default in Deployment Reports: Remember that business users are the audience in mind for this page. They do not understand our naming convention, and even if it’s decipherable, sometimes your reports are against the source table so there’s no easy way to sort and filter based on where they are registered. Further, you can’t use the Index column - multiple targets may have the same Index # I propose the ‘Target Index #’, ‘Dataset Name’ and ‘Dataset Description’ columns should be displayed here. The default sort should be based on Target Index # then Report Index #

jay.hornback@syniti.com about 2 months ago

1

Planned

Decouple Orchestrate from ETL IDs – Introduce Logical Name-Based Execution & Dynamic Resolution Layer

Problem Statement (Current Limitation) Syniti Orchestrate is currently designed with a tight coupling to system-generated ETL (Asset) IDs for workflow execution. As observed in the current implementation and internal usage: When ETL objects are re-imported (e.g., Golden → Load / DEV → QA), Syniti generates a new ETL ID Existing Orchestrate workflows still reference the old ETL ID, resulting in: Invalid package execution Workflow failure Runtime errors such as: “Could not find JobQueue with ID…” This requires manual re-mapping of ETL references within each workflow Architectural Gap (What is Missing) 1. Logical Abstraction Layer (Critical Missing Capability) No support for ETL Name-based binding System relies purely on physical ID (non-portable) instead of logical identity ✅ Expected: Workflow → Logical ETL Name → Runtime Resolution → Active ETL ID 2. Metadata Resolver / Late Binding Mechanism No runtime engine to dynamically resolve ETL references Workflows are resolved at design-time (early binding) instead of execution-time ✅ Missing: Resolver service that maps: ETL Name + Environment + Version → ETL ID 3. Environment-Agnostic Design Current design breaks during: Release copy ETL import/migration No portability across environments ✅ Missing: Cross-environment ETL reference persistence 4. Dynamic Version / Mock Handling Mock/version is statically embedded in workflows ✅ Missing: Variable-driven execution: ETL = Customer_Load Mock = Mock1 → Dynamically resolved at runtime 5. Auto-Rebinding / Self-Healing Capability No mechanism to detect: Same ETL name with new ID No automatic re-linking ✅ Missing: Auto-recovery mechanism: If ETL_ID not found → Lookup by Name → Rebind automatically 6. Governance & Impact Awareness No visibility into: Which workflows depend on which ETLs What breaks after re-import Developer Pain Points This design introduces significant operational friction: 🔴 Manual Effort Overhead Developers must: Identify failed ETL IDs Copy ETL names Manually reassign IDs in each workflow 🔴 Productivity Loss Repetitive tasks after every import/release No automation or reuse capability 🔴 Error-Prone Process High risk of: Incorrect mapping Missing updates Partial workflow failures 🔴 Frustration & Low Adoption Developers perceive Orchestrate as: Rigid Non-intelligent Not aligned with modern ETL orchestration standards Business / Project Impact 🔻 1.

Sunil Bhardwaj 2 months ago

1

Enhanced Feature Request: Replication-Standard-Aware EXP View Generation

Overview Syniti currently allows views to be generated, but the generated views are not fully aligned with the standards required by the replication process. As a result, developers must manually enhance the generated views before they are usable in the broader migration and replication framework. This feature request proposes enhancing the existing view-generation capability so that generated *_T_EXP views are not only structurally created from metadata, but are also aligned to the required replication standards from the start. The goal is to reduce manual rework, improve consistency, and ensure generated views are closer to production-ready. Current Gap The current generated views provide a useful starting point, but they often require manual updates to align with replication and migration development standards. Common manual enhancements include: adding required ETL/control fields applying standard null-handling logic applying consistent data type defaults aligning column order to expected target structures applying standard aliases adding source/reference fields including required legacy key fields ensuring generated fields match replication expectations applying consistent formatting and naming conventions adding object-specific joins or placeholders handling required fields that are not present in the source structure validating that generated output is compatible with downstream replication processes This means the generated views are helpful, but they are still incomplete from a developer productivity perspective. Proposed Enhancement Enhance the view-generation framework so that generated *_T_EXP views are built using configurable replication standards. The generator should not only ask: What columns exist in the target structure? It should also ask: What does the replication framework require this view to look like? The generated output should include standardized logic for: required control fields key fields default values data type handling nullability handling expected source aliases standard comments and section dividers target column ordering placeholder expressions for unresolved fields generation reasoning for each output field Example

maxtitov 2 months ago

2

Enhancement Request – PostgreSQL Editor Results Section Usability

We would like to request a few usability enhancements in the PostgreSQL Editor – Results section, based on our day‑to‑day usage. Observations / Current Limitations In the query results section, the horizontal scroll bar is only visible when scrolling to the very bottom of the page. This makes it inconvenient to view wide result sets with many columns. There is no option to copy multiple selected columns or the entire result set at once, unlike standard SQL editors (e.g., pgAdmin, SQL Developer). Currently, copying data is limited and time‑consuming for analysis and sharing. Requested Enhancements We request the following improvements in upcoming releases: Always‑visible horizontal scroll bar (or a fixed scroll bar at the top of the results grid) to easily navigate wide result sets. Ability to select and copy multiple columns, multiple rows, or the entire result set in one action. Option to copy results with column headers. These enhancements would significantly improve productivity and align the PostgreSQL editor experience with commonly used SQL tools. Please let us know if any of these features are already planned, or if additional inputs are required from our side. Thanks, Srikanth Vavilala

Srikanth Vavilala 2 months ago

1