Display both Total number of rows and number of filtered rows when a filter is applied
When no filter is applied in a grid, the total number of Rows is displayed. This is, for example, from Dataset Design. It displays there are 48 rows. After a filter is applied, the number of displayed rows is reduced, but the grid still displays the same number (48). It would be useful to display both the number of filtered rows and the number of total rows, so we can get a clear picture of how many records are affected by the filter we have applied vs the total number of rows in the list.
Rafael Domene about 7 hours ago
Migrate
Display both Total number of rows and number of filtered rows when a filter is applied
When no filter is applied in a grid, the total number of Rows is displayed. This is, for example, from Dataset Design. It displays there are 48 rows. After a filter is applied, the number of displayed rows is reduced, but the grid still displays the same number (48). It would be useful to display both the number of filtered rows and the number of total rows, so we can get a clear picture of how many records are affected by the filter we have applied vs the total number of rows in the list.
Rafael Domene about 7 hours ago
Migrate
Cloud Construct errors and warnings
When using validations and events in Cloud Construct the information displayed when a validation fails does not have any detail. Only the counts of warnings and errors. Add more info to the errors or warnings so users have the detail of what failed at the time of the event. It might also be useful to have some kind of hover functionality so that when a user hovers over the status field on a row they can see the list of warnings or failures
Derek Williams about 22 hours ago
Construct
Cloud Construct errors and warnings
When using validations and events in Cloud Construct the information displayed when a validation fails does not have any detail. Only the counts of warnings and errors. Add more info to the errors or warnings so users have the detail of what failed at the time of the event. It might also be useful to have some kind of hover functionality so that when a user hovers over the status field on a row they can see the list of warnings or failures
Derek Williams about 22 hours ago
Construct
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 5 days ago
Platform
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 5 days ago
Platform
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 5 days ago
Quality
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 5 days ago
Quality
Allow sorting & filtering in all the columns of the Replications grid
In Replicate Preview I can’t filter and sort all columns. Sorting & filtering columns “Last Refreshed” and “Record Count” can be very helpful, as we may need to check which were the most recent replications or the ones with more records / no records without having to export the data to Excel. Ideally, date & time display format for the “Last Refreshed” column should be customizable. It would be very nice that filtering for “Last Refreshed” column was similar to that existing in Excel, in which data is grouped by Year / Month / Day.
Rafael Domene 5 days ago
Replicate
Allow sorting & filtering in all the columns of the Replications grid
In Replicate Preview I can’t filter and sort all columns. Sorting & filtering columns “Last Refreshed” and “Record Count” can be very helpful, as we may need to check which were the most recent replications or the ones with more records / no records without having to export the data to Excel. Ideally, date & time display format for the “Last Refreshed” column should be customizable. It would be very nice that filtering for “Last Refreshed” column was similar to that existing in Excel, in which data is grouped by Year / Month / Day.
Rafael Domene 5 days ago
Replicate
Open "Give Us Feedback" in a new window
Open a new window when clicking the “Give Us Feedback” link, so we don’t lose our reference screen & work in ADMM. Ideally, fill some details by default. For example, fill the Module with the value of the Module that was in use when the “Give Us Feedback” link was clicked (but allow to change it manually).
Rafael Domene 5 days ago
Platform
Open "Give Us Feedback" in a new window
Open a new window when clicking the “Give Us Feedback” link, so we don’t lose our reference screen & work in ADMM. Ideally, fill some details by default. For example, fill the Module with the value of the Module that was in use when the “Give Us Feedback” link was clicked (but allow to change it manually).
Rafael Domene 5 days ago
Platform
Cloud Construct UI
When setting up webapps in cloud construct it would be helpful to have some easy navigation to excel import and also to SynitiDrive. In using the new Construct we are looking for ways to stay in the main app while working and this would be helpful.
Derek Williams 7 days ago
Construct
Cloud Construct UI
When setting up webapps in cloud construct it would be helpful to have some easy navigation to excel import and also to SynitiDrive. In using the new Construct we are looking for ways to stay in the main app while working and this would be helpful.
Derek Williams 7 days ago
Construct
Cloud Construct Table Add
When adding a new table to the Datastore we then have to go through several steps to setup the dataset for that table so it can be used in Cloud Construct. We need a way to create the dataset after we add and scan the table into a datastore. A button to create the dataset would be efficient and reduce the jumping out of Construct to get tables added
Derek Williams 7 days ago
Construct
Cloud Construct Table Add
When adding a new table to the Datastore we then have to go through several steps to setup the dataset for that table so it can be used in Cloud Construct. We need a way to create the dataset after we add and scan the table into a datastore. A button to create the dataset would be efficient and reduce the jumping out of Construct to get tables added
Derek Williams 7 days ago
Construct
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 7 days ago
Migrate
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 7 days ago
Migrate
Replication layout
Within Replicate preview there is the ability to filter certain columns like Source Table/Target Name, replication type and progress status. It would be really helpful to add filters to all columns for example Priority, Record Count, Volume (mb). Specifically record count and volume are helpful when reviewing data heavy Table’s to be able to identify them quickly rather than having to scroll up and down a large list. This was mentioned previously about a year ago: https://syniti.featurebase.app/p/replicate-results-in-admm-should-be-sortable but as yet still seems to be an issue within replicate preview anyway. Thanks
Christian Stratford 15 days ago
Replicate
Replication layout
Within Replicate preview there is the ability to filter certain columns like Source Table/Target Name, replication type and progress status. It would be really helpful to add filters to all columns for example Priority, Record Count, Volume (mb). Specifically record count and volume are helpful when reviewing data heavy Table’s to be able to identify them quickly rather than having to scroll up and down a large list. This was mentioned previously about a year ago: https://syniti.featurebase.app/p/replicate-results-in-admm-should-be-sortable but as yet still seems to be an issue within replicate preview anyway. Thanks
Christian Stratford 15 days ago
Replicate
Planned
Include Queries when comparing Implementation version history
Currently, when you go to an Implementation, select ‘Version History’, and then ‘Compare versions’, you see a screen that excludes the [Error Query] and [Opportunity Query] properties. This makes it so that you often cannot see why one version is different from the prior one. Please include the queries in the ‘compare’ page.
Ben Bauer 20 days ago
Quality
Planned
Include Queries when comparing Implementation version history
Currently, when you go to an Implementation, select ‘Version History’, and then ‘Compare versions’, you see a screen that excludes the [Error Query] and [Opportunity Query] properties. This makes it so that you often cannot see why one version is different from the prior one. Please include the queries in the ‘compare’ page.
Ben Bauer 20 days ago
Quality
User Deployment - Not in sync with SKP Users
Gaurav Kothari Jun 9, 2026, 09:36 EDT We noticed that users listed in ADMM -> Administer -> Security -> User Deployments are not updated UNLESS new SKP user clicks on Migrate button. We need to identify list of users who don't have any deployments assigned via SQL. Is there a way to get the list of users that are NOT listed in 'User Deployment', as user may not have clicked on Migrate app. We have a need to develop a system report to provide it to business team for follow-up.
Gaurav Kothari 22 days ago
Migrate
User Deployment - Not in sync with SKP Users
Gaurav Kothari Jun 9, 2026, 09:36 EDT We noticed that users listed in ADMM -> Administer -> Security -> User Deployments are not updated UNLESS new SKP user clicks on Migrate button. We need to identify list of users who don't have any deployments assigned via SQL. Is there a way to get the list of users that are NOT listed in 'User Deployment', as user may not have clicked on Migrate app. We have a need to develop a system report to provide it to business team for follow-up.
Gaurav Kothari 22 days ago
Migrate
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 23 days ago
Migrate
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 23 days ago
Migrate
ADMM - Excel Integration limits are too low
» Data Volume Limitations — The data volume limitation on imported spreadsheets cannot exceed 1000 rows and the file must be 1MB or less in file size. Otherwise, an error message will be shown. File size limit of 1MB is too low and should be increased.
Gaurav Kothari 27 days ago
Migrate
ADMM - Excel Integration limits are too low
» Data Volume Limitations — The data volume limitation on imported spreadsheets cannot exceed 1000 rows and the file must be 1MB or less in file size. Otherwise, an error message will be shown. File size limit of 1MB is too low and should be increased.
Gaurav Kothari 27 days ago
Migrate
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
Migrate
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
Migrate
Cloud Replicate - WHERE CLAUSE
Include the where clause to the replications_export file. Display an icon in the replications grid a where clause is configured on the replication. Provide a way to mass add a where clause to all replications, i.e. MANDANT at Source level for SAP extractions using ODBC connection.
Ana Garcia Rubio (Syniti) about 1 month ago
Replicate
Cloud Replicate - WHERE CLAUSE
Include the where clause to the replications_export file. Display an icon in the replications grid a where clause is configured on the replication. Provide a way to mass add a where clause to all replications, i.e. MANDANT at Source level for SAP extractions using ODBC connection.
Ana Garcia Rubio (Syniti) about 1 month ago
Replicate
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
Match
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
Match
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
Migrate
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
Migrate
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
Migrate
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
Migrate