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
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
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 about 6 hours 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 about 6 hours 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 2 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 2 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 2 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 2 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 2 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 2 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 10 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 10 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 15 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 15 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 17 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 17 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 22 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 22 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
Report to show the Audit Logs(Syniti change log report)
create a report which can show the Audit logs. Project team needs to see who has changed the mapping/dataset/rule in Syniti ADMM on which date and time or let us know if any report is available which can show the audit logs. Let us know if any existing report is available in your point of view! Project Release Dataset Changed By Change Description or artifact Changed on (date and Time)

Arun Sasi Maliyakkal about 2 months ago
Migrate
Report to show the Audit Logs(Syniti change log report)
create a report which can show the Audit logs. Project team needs to see who has changed the mapping/dataset/rule in Syniti ADMM on which date and time or let us know if any report is available which can show the audit logs. Let us know if any existing report is available in your point of view! Project Release Dataset Changed By Change Description or artifact Changed on (date and Time)

Arun Sasi Maliyakkal about 2 months ago
Migrate
Migration Execution Statistics report in Syniti ADMM Migrate
We need a migration execution statistics report. Below is the format of the report which will give execution statistics of a data migration object. KPI report should look like below Purpose: This report will give overall effort and time spent on an object. 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 open po 06 10:00 ekpo 30 213123 ok

Arun Sasi Maliyakkal about 2 months ago
Migrate
Migration Execution Statistics report in Syniti ADMM Migrate
We need a migration execution statistics report. Below is the format of the report which will give execution statistics of a data migration object. KPI report should look like below Purpose: This report will give overall effort and time spent on an object. 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 open po 06 10:00 ekpo 30 213123 ok

Arun Sasi Maliyakkal about 2 months ago
Migrate
Replicate Preview needs all Migrate Export features
Text Qualifier, Add Transactional Info, and Include Header Row are all features in the Migrate ETL Task, but not Replicate.

jay.hornback@syniti.com about 2 months ago
Replicate
Replicate Preview needs all Migrate Export features
Text Qualifier, Add Transactional Info, and Include Header Row are all features in the Migrate ETL Task, but not Replicate.

jay.hornback@syniti.com about 2 months ago
Replicate
Increment indexes in Replicate Preview
When adding Sources or Replications within Replicate Preview, it defaults Index = 1000 no matter what already exists. It should behave similarly to the rest of ADMM where it will +10 the max Index value.

jay.hornback@syniti.com about 2 months ago
Replicate
Increment indexes in Replicate Preview
When adding Sources or Replications within Replicate Preview, it defaults Index = 1000 no matter what already exists. It should behave similarly to the rest of ADMM where it will +10 the max Index value.

jay.hornback@syniti.com about 2 months ago
Replicate
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
Migrate
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
Migrate