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 17 minutes ago

Granular report in ETL transform Job List

Need more granular report in the ETL Transform Job List per data object level like below. This would help team to find time/effort spent per data object for each release and version. Kindly treat this as a feature request or handled by Services as it was discussed with Migrate Product Manager regarding the feasibility of building out the required report and as informed by then it is not straight forward due to transitory nature of the Job Queue details. Project Release Dataset name Subject area Execution date ETL tasks Run time in seconds Records processed Status BBM BBM_WB open po S2P 06 10:00 ekko 25 21312 ok BBM BBM_WB open po S2P 06 10:00 ekpo 30 213123 Ok @nikhileshshirsale @Jon Green Please consider this and forward it as a feature request

Arun Sasi Maliyakkal 2 days ago

1

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 1 month 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. Delivery Delays Every ETL re-import causes: Workflow breakage Rework cycles Directly impacts: Mock readiness Cutover timelines 🔻 2. Reduced Scalability Not suitable for: Large programs Multi-wave SAP migrations Parallel environment deployments 🔻 3. Increased Cost of Ownership Manual workaround → increased effort Dependency on skilled resources for trivial fixes 🔻 4. Runtime Instability Workflows fail silently or unpredictably Dependency on obsolete IDs leads to: Frequent runtime errors. 🧠 Architectural Recommendation (Proposed Enhancement) ✅ Introduce Logical ETL Binding Replace: ETL_ID (Hardcoded) With: ETL_NAME (Logical) + Runtime Resolver ✅ Introduce Metadata Resolution Layer [Workflow] ↓ [Logical ETL Name + Variables] ↓ [Resolver Engine] ↓ [Environment-Specific ETL ID] ↓ [Execution] ✅ Enable Variable-Driven Execution Mock / Version selection via variables Example: ${ENV} = LOAD ${MOCK} = MOCK1 ✅ Auto-Rebinding Engine Detect: Same ETL, new ID Automatically remap references ✅ Release-Aware Mapping Maintain mapping consistency across: Golden → Load → Production Expected Benefits ✅ For Developers Zero manual remapping Improved productivity Reduced errors ✅ For Architecture Loose coupling Environment-agnostic workflows Reusable orchestration design ✅ For Business Faster delivery Stable execution Reduced operational cost 🧾 Conclusion The current Orchestrate design is physically bound, environment-dependent, and operationally fragile due to its reliance on system-generated ETL IDs. Without introducing: Logical abstraction Runtime resolution Auto-rebinding …the platform will continue to face: Developer dissatisfaction Delivery delays Scalability limitations ✅ Final Recommendation (Concise) Introduce logical ETL name-based execution with a metadata-driven resolver layer and dynamic variable support, enabling Orchestrate to become environment-agnostic, self-healing, and scalable for enterprise-grade data migration programs.

Sunil Bhardwaj about 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 about 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 about 2 months ago

1

Enhanced Data Interaction Layer for Syniti UI

Summary Introduce a lightweight, non-invasive UI enhancement layer that improves how users interact with and interpret data within the existing platform. This solution overlays additional visual cues, intelligent filtering, and usability improvements without modifying the core application. Problem Statement Users working within the current interface face several friction points: Difficulty quickly identifying key data signals (errors, flags, statuses) High cognitive load when scanning large datasets or dropdowns Inefficient navigation due to lack of smart filtering or prioritization Repetitive manual effort to interpret or locate relevant information This results in: Slower task execution Increased risk of oversight or error Lower overall user efficiency and satisfaction Proposed Solution Implement a client-side enhancement layer that augments the existing UI with: 🔹 Visual Enhancements Dynamic color coding for key fields (e.g., status, errors, boolean flags) Priority-based highlighting (e.g., TRUE/FALSE overriding other styles) Improved contrast and readability for dense data grids 🔹 Intelligent Interaction Smart dropdown filtering with fuzzy/wildcard search (e.g., PMWC*CRCO) Auto-suggest top matches with preview lists Keyboard-driven selection (Enter to select best match) 🔹 Real-Time Responsiveness Lightweight refresh logic tied to DOM updates (MutationObserver-based) Efficient rendering using throttling (e.g., requestAnimationFrame) Adaptive updates as new data loads dynamically 🔹 User Productivity Features Quick-select panels for common values Reduced need for scrolling and manual searching Faster identification of actionable data Use Cases Data migration validation (preload/postload analysis) Error identification and remediation workflows Dropdown-heavy configuration tasks Large dataset navigation and filtering

maxtitov about 2 months ago

1