Independent IFS Cloud practice · Implementation
The business impact of implementing IFS Cloud ERP
Key takeaways
- The gains from IFS Cloud come from structure, not from features: site clusters, a shared parameter set, and a small number of automations that people actually use.
- Update-safe is a design decision taken on day one, not a cleanup job before an upgrade. What you build inside the Extensibility Framework survives R1/R2; what you build around it becomes your problem twice a year.
- Supply chain money leaks where nothing is broken: an order nobody confirmed, a receipt nobody invoiced, a price that changed quietly. None of it throws an error.
- AI in an ERP is only as good as the data discipline underneath it. Forecasting on a master data set nobody owns produces confident, well-formatted nonsense.
- Crystal Reports layouts do not carry across to IFS Cloud. The report inventory has to be triaged, not migrated, and the triage is the bigger job.
- Measure two or three things you were already arguing about before go-live. A benefits case with fifteen KPIs gets quietly abandoned by month four.
Most articles about ERP business impact are written from the brochure. This one is written from the projects. I have spent seventeen years inside IFS, from Apps 7.5 through Cloud, and the pattern that repeats is not that companies pick the wrong system. They pick a capable one and then implement it in a way that throws the capability away: a template nobody reuses, an automation layer nobody trusts, reports rebuilt one for one from the old system because nobody had the authority to delete any of them.
So this is not a list of what IFS Cloud can do. It is a walk through the places where a decision taken during implementation determines whether the platform pays for itself or just replaces one kind of manual work with another. Where a topic deserves its own treatment, I have linked to the longer piece on the ifs-erp.com blog rather than compressing it into two sentences here.
1.Site clusters, and the thing they actually save you
Grouping sites so they share parts, defaults and process setup is sold as a speed feature. It is really a consistency feature, and the speed is a side effect. When site four inherits the purchasing parameters that sites one to three already run on, you are not just saving a week of configuration. You are removing the possibility that site four quietly does receiving differently, which is what costs you two years later when someone tries to compare performance across the group and finds the numbers are not measuring the same event.
The catch is that a cluster only helps if the template being cloned is one somebody defended. Rolling out a bad standard quickly is worse than rolling it out slowly, because a slow rollout at least gives each site a chance to object. I ask for the template to be signed off by the person who will own the process across all sites, not by the site that happened to go first. That is also where the multi-site purchasing decisions belong: whether demand consolidates centrally, and how stock moves between sites once it has.
Further reading: centralised purchasing in IFS Cloud, distribution orders between sites, and from planning to go-live.
2.Automation without a development team
IFS Cloud gives you three tools that cover most of what people used to write code for, and knowing which one to reach for is the whole skill. A Quick Report reads data out: a saved query for a list or an extract, with no logic. A Custom Field stores something the standard data model does not. A Custom Event reacts when a row changes, and can hand off to a Workflow that routes an approval, sends a notification, or calls out to another system.
The failure mode is predictable. Teams discover Custom Events, like them, and attach one to everything. Six months later there is an event layer nobody can explain, firing on saves that were never meant to be significant, and the business has learned to ignore the notifications it produces. The second failure mode is subtler: reaching for a Custom Event when the requirement is actually a scheduled check. An event fires when a row changes. It cannot fire because a row has not changed, which is exactly what an unconfirmed order or an untouched receipt is.
Where the requirement crosses a system boundary, the answer is usually an interface rather than an in-system automation. IFS Cloud's OData projections are the normal integration surface, and keeping the orchestration outside IFS keeps that logic out of your ERP, where it would otherwise become one more thing to retest at every release.
Further reading: Custom Events explained, Quick Reports vs Custom Fields vs Custom Events, IFS Cloud API integration, orchestrating IFS Cloud with n8n. Work that has already been built once sits in the configurations and interfaces sections of the marketplace.
3.Customisation that survives the next release
IFS Cloud ships R1 and R2 every year. That cadence is the biggest single change in how you should think about customisation, and it is where legacy habits do the most damage. On Apps 9 or 10 an upgrade was an event you prepared for over months, so carrying technical debt between them felt survivable. On Cloud it arrives twice a year, and anything built outside the Extensibility Framework has to be checked, and often reworked, on that same rhythm.
The boundary is simple to state and easy to cross by accident. Extending the data model with Custom Fields, adding logic through Custom Events and Workflows, adapting screens through configuration: all inside the contract, all carried forward. Touching a core object, or building a report or an interface directly against an internal view rather than a published projection, puts you outside it. Nothing stops you at the time. The bill arrives at the next release, and at every release after that.
I have watched this go wrong in both directions. Companies that refuse all extension end up with a shadow layer of spreadsheets doing the work the system was not allowed to do, which is worse, because at least a customisation is visible. The honest position is that some extension is necessary, and the only real question is whether it is built where the platform will maintain it for you.
Further reading: update-safe extensions, the true cost of customisation, clean core in an SCM context, the upgrade tax, the upgrade readiness checklist, and what a release actually brings, with 25R2 purchasing as the worked example. Scoped modification work is listed under marketplace modifications.
4.Supply chain: the expensive leaks are all silent
Ask a buyer what goes wrong and you get something dramatic: a late shipment, a line stopped for a missing part. Look in the data and the costly problems are the undramatic ones, because nothing in the system objects to them.
| What is sitting there | Why nobody sees it | What it turns into |
|---|---|---|
| A released PO the supplier never acknowledged | The order is valid and open. No field says "ignored" | A delivery date everyone planned around that was never agreed |
| Goods received, invoice never matched | Both records are individually correct | An accrual that grows quietly until period end |
| A supplier price that moved between orders | The new price applies cleanly, exactly as configured | Margin erosion found during an annual review |
| A buyer who stopped ordering from a usual source | Every individual order is legitimate | Concentration risk, or a supplier problem nobody escalated |
All of this is detectable, and all of it is readable through standard OData projections on a read-only account. That means a monitor can look for it daily without touching a record, installing an object, or adding anything the next release has to be checked against. It is the design principle behind the SCM Automation Pack, and the reason the five-day exception scan exists as a way to see what is already in your own data before committing to anything ongoing.
On the physical side the same principle applies to warehouse work. Picking strategy and packing proposals are configuration decisions that quietly set your throughput ceiling, and they are rarely revisited after go-live.
Further reading: unconfirmed purchase orders, what unmatched receipts do at period end, supplier price changes, advanced picking strategies, the packing proposal.
5.AI, and the part the demo leaves out
Anomaly detection, demand forecasting and predictive maintenance are genuinely useful, and they all rest on the same unglamorous foundation: whether your master data is good enough for a model to learn from. A forecast built on lead times copied out of the legacy system in 2019 and never reviewed will be precise, confident and wrong, and it will be harder to challenge than a human guess because it arrives with a number attached.
The second thing the demo leaves out is what happens to the output. Detection is the easy half. The half that decides whether any of it pays off is routing: who receives the signal, how it reaches them, and what happens when they do nothing. An alert stream with no named owner and no escalation is a mailing list, and people unsubscribe from mailing lists in their heads long before they do it in the client.
That is why I design exception rules around the recipient rather than the condition. One deduplicated digest per owner per day beats forty individual notifications that are each technically correct. And a rule that cannot state in one sentence what the recipient is supposed to do about it does not ship.
Further reading: alert fatigue and exception design, the cost of missed exceptions, detecting supplier behaviour change, the data attention gap, assumed vs confirmed records, read-only OData monitoring.
6.Life after Crystal Reports
Crystal Reports layouts from Apps 9 and 10 do not carry across to IFS Cloud. That is the fact that matters for your plan, whatever any vendor's support calendar says, and it is usually discovered later than it should be, because reporting gets treated as a workstream that can start once the real configuration is done.
IFS Cloud splits the job across different tools. Quick Reports handle lists and extracts: saved queries, no layout ambition, self-service for anyone who can be trusted with a data set. Laid-out business documents are produced through IFS Cloud's own report layout tooling. Analysis and dashboards belong in the reporting and analytics layer rather than in a printed report at all. Trying to recreate a 200-item Crystal inventory inside any one of these is how reporting becomes the critical path.
The work that actually saves you time is triage, and it is a business job rather than a technical one. Pull the usage data first. Most report inventories contain a long tail nobody has run in two years, a middle band that exists because one person likes the format, and a small core the business genuinely runs on. Rebuild the core properly, convert the middle band to Quick Reports or a dashboard, retire the tail. The conversation about retiring the tail is the hard part, which is why it needs to start early and needs someone senior to close it.
Further reading: when a Quick Report is the right answer, and the reports section of the marketplace.
7.Access, segregation of duties, and the audit you have not had yet
Permission sets in IFS Cloud are capable enough to express proper segregation of duties. Whether they end up doing so is decided in the first six weeks of the project, when someone is under time pressure and the fastest way to unblock testing is to grant a broad set to a group and move on. That grant is almost never revisited, because nothing breaks. It surfaces at the first external audit, when a tester asks who can both create a supplier and approve a payment to it, and the honest answer takes a fortnight to assemble.
Design the role model against the process rather than the org chart, and build it while the process design is still fresh in everyone's head. It costs days then and weeks later. The same applies to standards work: if you operate under ISO requirements, the evidence those audits want is largely a by-product of decisions you are already taking, provided you record them as you go instead of reconstructing them afterwards.
Further reading: RBAC and segregation of duties, permission sets in IFS Cloud, ISO standards in IFS Cloud, and the security section of the marketplace. My own view on the wider ownership question sits on the data governance page.
8.Data migration, which quietly owns your go-live date
Every implementation plan has a migration workstream, and most are optimistic by the same margin. The reason is consistent: the effort is not in loading the data, it is in deciding what the data should say. Loading is mechanical. Agreeing that these 4,000 part records are the ones worth keeping, that this status code maps to that one, and that a customer with no valid tax ID is a customer you are not going to migrate, is a series of business decisions with no obvious owner.
Two habits change the outcome. Rehearse the load more than once, on a schedule, with a defined cut of source data each time, so the failure list shrinks between rehearsals instead of being discovered on cutover weekend. And treat validation as its own deliverable with its own sign-off rather than as the last step of loading, because IFS Cloud enforces its business rules at load time: well-formed source data can still be rejected for violating application logic nobody had read.
Further reading: the data migration checklist, how FNDMIG and the Data Migration Manager fit together, and the data migration section of the marketplace.
9.The risk that is not in the software
In most of the companies I work with, a large amount of operational knowledge lives in one person's head and one person's spreadsheet. The buyer who knows which supplier actually delivers on time regardless of what the lead time field says. The planner whose workbook reconciles two things the system does not reconcile. None of this shows up in an ERP assessment, and all of it walks out of the building when that person leaves.
An implementation is the one moment when you have a mandate to surface it. Every shadow spreadsheet is a documented requirement waiting to be read: it exists because the system does not do something, and finding out what that something is tells you more about your real process than a workshop will. Some of them should become configuration. Some should become a Quick Report. A few are genuinely someone's judgement and should stay human, but at least then you know where they are.
The same logic applies to the implementation record itself. Decisions taken in month two get questioned in month eleven by people who were not in the room, and a project that cannot answer "why is it set up this way" reopens settled arguments for the rest of its life.
Further reading: shadow spreadsheet risk, knowledge loss when people leave, buyer knowledge concentration, and the implementation documentation kit if you would rather not build the templates from scratch.
10.What to measure, and how to keep measuring it
I am wary of quoting percentage improvements. Published ranges come from situations you cannot inspect, with baselines nobody defined, and a number borrowed from another company's business case is not evidence about yours. What I can offer is the short list of measures that survive contact with an actual steering committee.
- Pick metrics you were already arguing about. If nobody argued about on-time supplier delivery before the project, nobody will defend it as a benefit afterwards.
- Take the baseline before go-live, from the old system. This is tedious and it is the only chance you get. A benefit you cannot baseline is a benefit you will eventually be asked to withdraw.
- Keep it to three. Fifteen KPIs is a spreadsheet that gets maintained for four months. Three get reported for years.
- Separate "we saved money" from "we can now see it". Visibility is a real benefit and a different one. Claiming it as cash is how a benefits case loses credibility.
- Re-measure on a fixed date, not when it looks good. A quarterly slot in the calendar, owned by a named person, beats an ad hoc review after a good month.
Further reading: ERP ROI analysis, why go-live is a load test, the implementation crisis.
11.Where to start if you are already mid-flight
If you are live on IFS Cloud and this article has described your situation rather than your plan, the order that works is roughly this. Find out what is actually in your data before redesigning anything, because the exception population usually contradicts the received wisdom about where the problems are. Then fix the governance decisions that get harder with time: the role model, the report inventory, the ownership of master data. Automation comes after that, not before, because automating a process nobody owns only makes it produce wrong answers faster.
What I do is on the offer page, the platform view is on the IFS Cloud page, and the process side sits under business process optimisation. The applications themselves, including the read-only exception monitoring described in section 4, live on ifs-erp.com.
12.Frequently asked questions
Is it too late to make an implementation update-safe if we are already live?
No, but the work changes shape. Before go-live it is a design decision that costs nothing extra. After go-live it is an inventory exercise: list everything built outside the Extensibility Framework, establish what each item actually does, and decide case by case whether to rebuild it inside the contract, replace it with standard functionality, or accept the maintenance cost knowingly. The last option is legitimate. What is not legitimate is not knowing which category each item falls into, which is the usual starting position.
Do we need AI features to get value out of IFS Cloud?
No. In most projects I see, the unclaimed value sits in exceptions a plain query would find: orders nobody confirmed, receipts nobody invoiced, prices that moved. That is rule-based detection rather than machine learning, and it works on data that is merely adequate. Model-driven forecasting is worth doing once master data has an owner and a maintenance routine, and worth postponing until it does.
Can exception monitoring be added without installing anything in our IFS Cloud?
Yes, and that is the approach I prefer for anything that only needs to read. Standard OData projections plus an integration account with read permission are enough to detect the exception patterns in section 4. Nothing is installed in IFS, nothing is written back, and there is no object for the next R1 or R2 release to break. If you want to see the output before committing to anything ongoing, the five-day exception scan produces the same report in observation mode only.
How long should we allow for moving off Crystal Reports?
Budget the triage, not the rebuild. Pulling usage statistics and getting a decision on what to retire takes longer than rebuilding the reports that survive, because it needs business sign-off rather than developer time. Start it in parallel with configuration rather than after it, and give the retire list an owner with the authority to say no. Teams that skip this step rebuild everything one for one and carry the whole inventory forward, including the part nobody has opened since 2019.
Are site clusters worth it for only two or three sites?
The configuration saving is small at that scale. The consistency saving is not, and it compounds: two sites configured independently will diverge on receiving, costing and reporting definitions within a couple of years, and reconciling them later is considerably more work than agreeing a shared template now. If there is any prospect of a fourth site, an acquisition, or a group-level report, treat it as worth it.
13.About the author
Dariusz Myśliwiec: 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Want to know which of these applies to your implementation?
If you are scoping an IFS Cloud implementation, or you are already live and suspect the value case has quietly gone missing, a short call is the fastest way to work out which two or three of the eleven sections above are actually costing you something.
- Details
IFS Cloud | Data Migration
Run an IFS Data Migration Manager load from scope to reconciliation, in the order the tool expects
IFS Data Migration Manager (DMM) is the Solution Manager tool that takes legacy data through a fixed path: a migration project, legacy load, mapping, Input Container, Output Container, Deployment Container. Only records that pass validation and are approved reach IFS Cloud, and every container keeps its own status fields as evidence. This guide walks that path step by step, is based on the 25R1 Data Migration Manager pages of the Technical Documentation for IFS Cloud and marks where the older Migration Jobs tool (FNDMIG) answers a different question.
Key takeaways
- DMM and Migration Jobs are two tools with different vocabulary. DMM has projects, containers and mappings; Migration Jobs has a Job ID, a Method List and Source Mapping. Instructions written for one tool do not match the screens of the other.
- The DMM path is fixed: scope, target table definition, legacy load (CSV), lock, mapping, Input Container, Output Container, Deployment Container. Each stage has its own status fields, so each stage leaves proof.
- Basic data comes before master and transactional data. Basic Data Validation checks references against approved values, so a transactional record cannot be approved before the parts, sites or codes it points to.
- Deploy Without Commit rolls back and writes its result to the Deploy Message field. Only Deploy With Commit updates Deploy Status and Deploy Date Time, so rehearsals in a test environment use the first and the cutover uses the second.
- A load that finishes is not a load that is right. Reconcile counts and values per target table after every deployment, because validation cannot tell a legal wrong value from a legal right one.
This guide gives the hands-on order of a DMM load: which screen, in which sequence, and what evidence to keep before moving on. It builds on the role of the Data Migration Manager, the migration plan and the silent killers article. Where the documentation does not name a screen path or a permission set, the text says so instead of guessing.
1.What is IFS Data Migration Manager, and when do you use it instead of Migration Jobs?
Data Migration Manager is the end-to-end migration tool in IFS Cloud Solution Manager, where a Migration Project holds the scope, the legacy data, the mappings and the validation rules, and data moves through containers before it is deployed. On community.ifs.com it is described as the successor of Smart Data Manager, which is why older posts and training badges use that name.
The older Data Migration tool (documented under Data Management, Data Migration, and known as FNDMIG) works differently. You build a migration job with a Job ID, a Procedure Name, a Method List and a Source Mapping, and the job loads rows through the New__ and Modify__ methods of the business logic. The documentation says this keeps business rules and validations in force, because data does not go straight into tables. Both tools exist in current releases, and the questions about migration jobs, Excel logs or deleting records belong to the second one.
| Question | Data Migration Manager (DMM) | Migration Jobs (FNDMIG) |
|---|---|---|
| Unit of work | Migration Project with migration objects and target tables | Single migration job per table or logical unit |
| Where data waits | Legacy Data, Input, Output, Basic Data and Deployment Containers | Job details of the executed job; Details tab in Execute Job |
| Source format | CSV files into the legacy data container | Files, Oracle sources, and Excel through the IFS Data Migration Excel Add-In |
| Strength | Rules, validation, duplicate control and approval across many tables | Flexible per-table work, mass updates, custom transformation logic |
| Cost of flexibility | Heavy configuration up front and interlinked dependencies (community experience) | More hand-built logic that has to be tested and kept |
A thread on community.ifs.com about best practice for 24.1.3 summarises the trade-off the same way: DMM fits migrations with well-prepared source data and many validation rules, while FNDMIG is chosen for numbering conversions and non-master-data areas, and both can run on one project. A DMM container can reject data that a Migration Job would load, so decide per area, not once per project.
2.What must be in place before the first load?
Before a first load, the Migration Project needs its basic data: sources, connected environments, migration object scope and target table scope. Main Processes and Sprints are optional, according to the 25R1 documentation of Define Migration Project.
- Installed and connected environments: the environment where DMM runs is the installed environment and is usually PROD for security reasons. Other environments are connected through a database link name that Cloud Operations creates, and no links to PROD are created.
- Sources: every legacy system gets a source with a name, a date format, thousand separator and decimal point. Source priority drives duplicate elimination, and priorities 1 to 9 are reserved for sources created from environments.
- Template project: a project can start from a template with predefined migration objects, target tables, conversion lists and additional deployment processes. Importing a template requires the Migration Project Header first.
- Test environment: the first deployment goes to a non-production target. Rehearse in test, then repeat the same steps for production.
- Clean source files: check character set, decimal separator and date mask before the load, since the formats you define on import override those of the file.
Permissions are the part the documentation leaves open. The 25R1 Data Migration Manager pages do not name a permission set. For the Migration Jobs tool, the documentation describes an Authorized Users form that gives some users full access and others only query and start rights through Execute Job. On community.ifs.com, a user reported that someone who was not an authorized user could not see jobs created by others, even with broad projection access, and an IFS community expert named FND_ADMIN_FNDMIG as the out-of-the-box permission set to duplicate and reduce for a job-level role. Treat that as community guidance, check the set names in your own release, and keep the principle from permission sets and segregation of duties: the migration user is a named, reviewed account, not a shared administrator. In 24R2, a community poster found the menu under Data Management, Data Migration, Migration Jobs, so menu paths differ by version.
3.What are the core objects in DMM?
Seven objects carry a DMM migration, and the container names are literal screen names in the documentation.
- Migration Project: the main record that holds all project settings.
- Migration Object: the core element of the scope, defined in Project Basic Data. It contains target tables, and every target table used to load data into IFS must be bound to a migration object.
- Target Table: the IFS view that receives data. The Target Table Definition stores its metadata: field type and length, mandatory, key, input and updatable flags, letter case and enumeration values.
- Legacy Data and Legacy Table Definition: the imported CSV files, each load numbered with a Load Sequence.
- Mapping: a Mapping Header for a project, a legacy source and a migration object, with detail lines per target field.
- Containers: the Input Container (staging), Output Container (transformed data considered for deployment), Basic Data Container (reference data) and Deployment Container (approved records ready to deploy).
- Transformation Rules and Conversion Lists: the two mechanisms that change values on the way from Input to Output.
The Input, Output and Deployment Containers share one generic layout of 12 key field columns and 400 non-key columns, each field up to 4000 characters, with a message column beside every field. That is why a validation message always sits next to the value it describes.
4.How do you run a basic data migration in DMM, step by step?
The sequence below follows the order of the 25R1 Data Migration Manager pages. Run it first for one small table with a few rows, trace the rows from legacy file to Output Container, and only then scale up.
Step 1: Define the project and the scope
Create the Migration Project Header with an ID, a name and the date and number formats DMM should display, then connect a template if you use one. Build the Migration Object Scope in Project Basic Data and generate the Target Table Scope from it. Each target table is classified as Master Data, Transactional Data, Basic Data LOV or Basic Data Set Up, and Referenced Table Relationships can pull in the reference tables a target depends on. A 21R2 option limits that expansion to one level, which keeps scope from growing out of control. Targets that belong to an object are locked by default, and you unlock one before taking it out of scope.
Step 2: Create the target table definitions
For every in-scope target, create the Target Table Definition from the template or the master environment, and then create the metadata lines in the Input Container with the ALL source. The definition extraction picks up custom fields and user-defined fields, so repeat it after customisation changes. Read the flags: key fields that are not insertable are set to Autogenerated, and read-only fields are set Out of Scope. You can pick up to five columns for the duplicate check here.
Step 3: Prepare and export the mapping template
Use the command that exports Migration Object Details in Scope to get an Excel workbook with one sheet per in-scope target table and its fields. This is the document your data owners fill from, and it only contains field details if the definitions from step 2 exist. DMM itself imports CSV, so the extract from the legacy system is delivered as CSV.
Step 4: Load the legacy data and lock the load
Define the Legacy Data Header with the project ID, the source and the legacy data table name, describe the file (character set, field delimiter, string delimiter, date and number format) and choose client or server import. Client loads can run Online or in Background, and Background is recommended for many rows. The server load uses Oracle external tables and, per the documentation, is not available in the public cloud. Each import receives a Load Sequence number. Lock the load: only a locked load can be attached to a mapping, one load can be locked per legacy table, and locking creates the Legacy Table Definition. If a later load differs in structure, DMM warns you, so one mapping serves loads of the same layout.
Step 5: Map legacy fields to the target table
Create the Mapping Header with the Project ID, the Legacy Source ID and a Migration Object that is in scope and has its target table definitions. You can map one legacy column, a concatenation of two, or a legacy SQL column, add a prefix or suffix as a literal in single quotes, or fall back to default values. Smart Mapping suggests pairings by comparing field names, scores each from 0 to 100 and lets you set the accuracy threshold, then you review the suggestions and use Update Original mapping. If the same target is mapped twice, DMM appends a hash and the sequence number, and both mappings load into one target table.
Step 6: Transfer to the Input Container and test with a subset
Use the subset transfer to test the mapping first. Records from it are marked Test, are for testing only and cannot be processed further, and the option is unavailable after a full transfer until you delete the data. Then transfer everything, optionally with Meta Data Validation in the same run. The transfer compares the incoming rows with the Input Container and sets Record Status to New, Modified, Existing or Deleted.
Step 7: Validate and fix in the Input Container
Set the filters for a migration object and target table first, because the container shows nothing without them. Run Meta Data Validation for the source: errors set Data Status to Error and the message column next to the field says why. Fix by transformation rule (the link on the Transformation Rules metadata row) or by Conversion List, where Autofill Conversion List can add All, Missing or Erroneous values and marks new entries with seven asterisks so you see what is still to fill. Then run Check for Duplicates, decide each pair with Exclude from Transfer or a source-specific conversion of the ID, and rerun the check. The only columns a user can edit in this container are Exclude from Transfer and Exclude Comment.
Step 8: Transfer to Output, validate against basic data, approve
Transfer to Output applies the transformation rules. In the Output Container, Basic Data Validation looks for the referenced value in the Validation Target environment of the target table definition, then in the environment from the project's basic data setup, and otherwise in the Basic Data Container and approved Output Container records. If a reference is missing, either transform the value and transfer again, or use Basic Data Extraction to copy the missing value into the Basic Data Container, validate and approve it there, and revalidate the Output Container. A record without errors is set to Approved, and only approved records appear in the Deployment Container.
Step 9: Deploy without commit, read the result, then deploy with commit
In the Deployment Container, existing records are updated through Modify__ and new ones inserted through New__, unless you define an Other Deployment Method. Deploy Without Commit tests for errors and rolls back, and the result is in the Deploy Message field. Deploy With Commit writes and commits, fetches generated keys into the Target Key columns and is the only option that updates Deploy Status and Deploy Date Time. Pre and post deployment processes per target table exist for calculated values and status changes, and an SQL statement process must start with SELECT or WITH, runs once per record and does not allow DML or DDL.
Step 10: Schedule when the project is stable
Once scope, target tables, legacy data and mappings are complete, create a schedule job under Solution Manager, Data Management, Data Migration Manager, Data Migration Manager Schedule Jobs, New Schedule Job. The wizard has four pages: job details, target table details, job setup (including deploy with or without commit and where the process stops) and schedule. The job becomes Active only if the project has no validation errors. Otherwise it stays in planning until you fix what the Validation Info log lists.
5.In what order do basic, master and transactional data go?
Basic data goes first because DMM validates references against approved values. The Target Table Scope classifies tables as Master Data, Transactional Data, Basic Data LOV and Basic Data Set Up. Master and transactional tables are mapped against legacy tables, while the two basic data classes live in the Basic Data Container and are fed by extractions from the Output Container or from target environments.
In practice the order follows the references. Codes, sites and units come first, then master data that points to them, and transactional records last, such as opening balances, open orders or invoices that need the parts, customers or suppliers already approved. The scope view helps here: it shows for each target how many reference tables it has and how many of them are out of scope, so a transactional load with an out-of-scope reference is visible before it fails. The Deployment Container does not show a migration object until a mapping for it exists (one community thread on a missing Customer object suggests creating the mapping of legacy tables to the migration object and refreshing the page; the thread does not confirm which fix worked), so check the mapping and approved records before suspecting permissions.
Cutover is the same sequence run under time pressure. Rehearse the cutover at least once before go-live, and repeat until the reconciliation results are clean, using a fresh extract each time in a test environment. Record how long each stage takes, and fold every manual correction back into the extract or into a transformation rule. A fix applied only inside a spreadsheet will not exist at the next rehearsal, which is how the quiet failures described in data migration as a business reset start. The master data side of the plan is covered in implementing IFS Cloud master data, and the overall phases in the IFS Cloud ERP implementation guide. For the plan itself, the Data Migration Plan and Customer Data Readiness Checklist (IDK-15) gives a per-object load order, sign-offs and a cycle calendar.
6.Which errors will you meet, and how do you read them?
| Symptom | Where to look | Usual cause and fix |
|---|---|---|
| Data Status shows Error in Input or Output | Message column beside the field | Metadata rule broken (mandatory, length, letter case, enumeration). Add a transformation rule or Conversion List and transfer again. |
| Basic data error in Output | Message column and the Validation Target setting | Referenced value not approved. Transform the value, or extract it into the Basic Data Container, approve it and revalidate. |
| Legacy table cannot be attached to the mapping | Legacy load list | The load is not locked. Lock it, which also creates the Legacy Table Definition. |
| Subset transfer not offered | Mapping transfer options | A full transfer already happened. Delete the data first. |
| Migration object missing in the Deployment Container | Mapping for the object; approved records in Output | Community suggestions: create the mapping for the object, make sure records are approved, refresh the page. Confirm on your release. |
| Nothing deployed after Deploy Without Commit | Deploy Message | By design: the transaction is rolled back. Status fields change only with commit. |
| Scheduled job not active, or in Warning | Validation Info; background job details | Project validation errors, or a second run started while one was active. Only one run per scheduled job is processed. |
For Migration Jobs the reading order differs. The Last Info field of Execute Job holds the log of the last execution and the Details tab holds row-level messages. For source jobs, double-click the Attribute String and Error Message columns, fix what is fixable and use Restart Online. If the error comes from the input file, use Clean Up and run the corrected file from the start. When the cause stays unclear, open the Debug Console before restarting and read the trace of the Start_Job call. The business logic messages are the same ones you would get typing the record by hand, and entering a similar record manually with the console open is the documentation's own tip.
Errors that never appear in these places, such as a wrong unit conversion that loads cleanly, are described in the silent killers article, and the reconciliation list below is how you catch them.
7.What do you check before you call a load reconciled?
A load is reconciled when counts and values in IFS Cloud match an agreed figure from the source, per target table, and someone other than the loader has signed it.
- Row counts per stage: legacy rows loaded, rows by Data Status in the Input Container, approved rows in the Output Container, rows deployed with commit. Every difference has a reason: excluded, duplicate or error.
- Excluded records: each Exclude from Transfer carries an Exclude Comment, so the list is explainable.
- Control totals: stock quantity and value per site, open order value, open invoice balance, compared with the legacy report on the cutover date.
- Sample check: a set of records opened in the IFS Cloud client and compared field by field with the source, including units of measure and statuses.
- Referential check: no deployed record points to a code or parent that is missing or unapproved.
- Repeatability: a repeated rehearsal produces the same counts.
- Sign-off: the data owner confirms the reconciliation sheet, which then feeds UAT. A tracker for it is in the UAT test tracker template.
8.Step, action and evidence to keep
| Step | Action | Evidence or output to keep |
|---|---|---|
| 1. Scope | Create project, migration objects, Target Table Scope | Scope list with class per table and the out-of-scope references |
| 2. Definitions | Create Target Table Definitions and ALL-source metadata lines | Definition extraction date and the flags changed by hand |
| 3. Template | Export Migration Object Details in Scope to Excel | The workbook sent to data owners |
| 4. Legacy load | Import CSV, lock the load | Load Sequence number, source row count, locked Legacy Table Definition |
| 5. Mapping | Create Mapping Header, Smart Mapping, review | Exported mapping file, threshold used |
| 6. Input | Subset transfer, then full transfer, Meta Data Validation | Counts by Record Status and Data Status |
| 7. Cleansing | Transformation rules, Conversion Lists, duplicate check | Rule and list export, duplicate decisions with Exclude Comment |
| 8. Output | Transfer to Output, Basic Data Validation, approve | Approved count per target table, open errors at zero |
| 9. Deploy | Deploy Without Commit, then With Commit | Deploy Message per record; Deploy Status, Deploy Date Time and Target Key values |
| 10. Schedule | New Schedule Job, activate, run | Validation Info, Last Info and background job details per target table and environment |
| 11. Reconcile | Counts, control totals, samples | Signed reconciliation sheet per rehearsal and for cutover |
Book a 30-minute migration call Professional data migration services
9.Frequently asked questions
What is the difference between IFS Data Migration Manager and a migration job?
IFS Data Migration Manager runs a whole migration project through a Legacy Data Container, an Input Container, an Output Container and a Deployment Container with rules, validation and approval. A migration job in the Data Migration tool (FNDMIG) migrates one table or logical unit through a Method List and Source Mapping. Both can run in one project, chosen per data area, as the 24.1.3 best-practice thread on community.ifs.com describes.
Can Data Migration Manager load an Excel file?
The 25R1 documentation of the Data Migration Manager legacy load describes CSV files only, so Excel data is saved as CSV first. Direct Excel input belongs to the Migration Jobs tool: a job with the procedure EXCEL_MIGRATION and the IFS Data Migration Excel Add-In, which shows debug traces in a Logs section of the add-in. Licensing and permission set for the add-in are not covered here, so confirm them with IFS for your release.
Which permissions does a user need to run IFS Cloud data migration?
The IFS documentation for Data Migration Manager does not name a permission set. For Migration Jobs, the Authorized Users form decides who has full access and who can only query and start jobs, and community.ifs.com names FND_ADMIN_FNDMIG as the out-of-the-box set to copy and restrict. The migration user also needs access to the projections of the data being loaded, so verify the names in your release.
How do you delete records with an IFS migration job?
According to an answer by IFS staff on community.ifs.com, the common pattern is a migration job whose Method List calls the Remove__ procedure of the logical unit, with a Where Clause selecting the rows and the OBJID, OBJVERSION and ROWID fields mapped. The same answer sets the default of the ACTION field to DO and warns to check that the select fetches the correct lines. Test on a non-production copy first, because the business logic can refuse a removal.
How do you use a value created by an earlier step in a migration job?
In a Migration Job, the system keeps the attribute string and OUT parameters of each method in memory for the current row, and a later method in the Method List refers to them as item-name@method-sequence. The IFS example takes a generated TECHNICAL_SPEC_NO from method 10 and passes it into Technical_Spec_Alphanum_API.New__ for the same row.
Why did a Deploy Without Commit show no data in IFS Cloud?
Deploy Without Commit in the Data Migration Manager Deployment Container tests the records and rolls the transaction back at the end, so no data stays in the target. The outcome per record is written to the Deploy Message field, and Deploy Status and Deploy Date Time are updated only by Deploy With Commit.
10.Sources and what this guide does not claim
- IFS Cloud Technical Documentation 25R1, Data Migration Manager. The pages read for this guide: Define Migration Project, Migration Scope, Target Table Definition, Legacy Source Data Import, Map Legacy Data Target Table, Input Container, Output Container, Basic Data Container, Deployment Container and Schedule Migration Jobs. The Extra Configurations page was not read.
- IFS Cloud Technical Documentation 24R2, Data Migration. The pages read: the Data Migration overview, Execute Job, Excel Migration, Migration History Analysis, Authorized Users, Known Limitations, Handling Error Messages and Debug Info, and Parsing Variables Between Methods.
- IFS Community threads: best practices for 24.1.3, permission sets for migration jobs, deleting data with migration and a missing migration object in the Deployment Container. These are user and staff answers, not release documentation.
The documentation text was read as published for 25R1 and 24R2 and was not tested against a live system for this article. Menu paths are given only where the documentation states them. Permission set names come from community answers, and the details above (container sizes, source priorities, flags, wizard pages, menu paths) can differ between releases, so confirm each against your own IFS Cloud version and test environment before relying on it.
11.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud), including data migrations with FndMig and Data Migration Manager. IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who does the work.
Selected clients: Betafence (PRÆSIDIAD) · Newag · RADPOL · Fugro · NGK Ceramics · ATLAS.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Rehearse the load before it counts
Tell me which data areas you plan to move and which tool you intend to use for each. On a 30-minute call I will go through scope, load order and the reconciliation evidence you need for each rehearsal.
- Details
An IFS UAT test tracker is a register with one row per business scenario that proves business users tested and accepted an IFS Cloud solution or release upgrade. The template below has 16 columns, eight filled-in supply chain and finance rows, severity levels, go/no-go rules and a CSV block you can paste into Excel.
The structure splits ownership three ways: the business owns scenarios and sign-off, the project owns defects and cadence, and the IFS consultant owns fixes and retest readiness. The sections below follow that split.
Key takeaways
- One row equals one scenario, executed by a business user logged in with the permission set of the production role, never an administrator user.
- Two columns decide what UAT can prove and are easy to leave out: permission set used and sign-off; without them UAT cannot show that access design and acceptance were tested.
- Severity needs four levels and a written rule per level; an open S1, or an S2 in a critical process without written acceptance, means no-go.
- A daily 30-minute triage keeps the defect log honest: every defect gets a severity, an owner and a target build before the meeting ends.
- The IFS Scope Tool is reported to produce manual Test Trackers per scenario; no public IFS documentation of the function was found, so confirm the format with your Solution Architect before building on it.
What is an IFS UAT test tracker and who owns each part?
A UAT test tracker is the single list of scenarios, results and approvals that a business uses to decide whether to go live. It sits between the process design and the go-live decision, so each part has one accountable owner, listed below. For how UAT fits the IFS implementation phases, see Definition of UAT based on the IFS implementation methodology; for the wider test strategy, see IFS Testing: A Technical Perspective for Implementation Success.
| Part of the tracker | Owner | What they do |
|---|---|---|
| Scenario list and expected results | Business process owner | Confirms the scenarios cover the process and signs the expected result as correct |
| Execution and evidence | Key users and expert users | Run the steps with their own production permission set, record the actual result and attach evidence |
| Defect log and severity | Test lead (project side) | Opens the defect, proposes severity, runs the daily triage and keeps the counts honest |
| Fix and retest readiness | IFS consultant or partner, developer for CRIMs | Resolves configuration and custom-code defects and tells the test lead which build or release carries the fix |
| Permission set column | Security or permission owner | Keeps the mapping from business role to permission set and confirms testers are not using an admin user |
| Sign-off | Business process owner, then project sponsor | Signs per process area once exit criteria are met; the sponsor signs the go decision |
The IFS application has its own meaning of "role": a permission set grants access to pages and actions, while the UAT role is the job a person does in the process. The tracker maps one to the other in two columns, so a failed scenario can be traced either to the process or to the access design. The segregation-of-duties side is covered in permission sets and segregation of duties and precision permission set configuration.
What does a copy-ready IFS Cloud test tracker template contain?
The template has 16 columns, split here into a design block (filled before the cycle) and an execution block (filled during it), joined by the ID. Use the column guide first, then the example rows.
Column guide
| Column | What goes in it | Who fills it |
|---|---|---|
| ID | Stable key such as P2P-01. Never renumbered, so defects and sign-off keep pointing at the same row | Test lead |
| Process area, Scenario | The business process and one testable outcome, written as a sentence a key user recognises | Process owner |
| Business role, Permission set used | The job role and the exact permission set the tester logs in with | Process owner, permission owner |
| Test data | The concrete records needed (part, supplier, customer, amounts), so a second tester can repeat the run | Key user |
| Steps, Expected result | Numbered actions and the observable result, including statuses and postings where they matter | Key user, IFS consultant |
| Actual result, Status | What happened, and one of: Not started, In progress, Passed, Failed, Blocked, Passed on retest, Deferred (agreed) | Tester |
| Defect ID, Severity | Reference to the defect log and S1 to S4 from the severity table below | Tester proposes, triage confirms |
| Tester, Date | Name and date of the run; for a retest, of the latest run | Tester |
| Retest | Build or release in which the fix was verified, and the result | Tester |
| Sign-off | Name and date of the process owner who accepts this scenario or the process area | Process owner |
Design block with example rows
The permission set names are placeholders for your own naming. Replace the expected results with your configured behaviour: authorization rules, routing templates and ownership transfer points differ per company, and status names should be checked in your release.
| ID | Process area | Scenario | Business role | Permission set used | Test data | Steps | Expected result |
|---|---|---|---|---|---|---|---|
| P2P-01 | Procurement | Requisition above the authorization rule limit is routed to the approver | Requisitioner, then Department manager | ZREQ_REQUESTER and ZREQ_APPROVER (customer-defined) | Requisition for a stocked part, value above the rule limit | 1 Create and release the requisition. 2 Check that authorization is required for it. 3 Approver authorizes the requisition lines | Requisition shows as authorized after the approver acts (check the exact status names in your release). A line that still needs authorization cannot be converted to a PO |
| P2P-02 | Procurement | Authorized requisition line converts to a purchase order | Buyer | ZPUR_BUYER (customer-defined) | Authorized line from P2P-01, supplier with a valid price | 1 Convert the requisition line to a purchase order. 2 Release the order | PO is created for the right supplier, quantity and price. If a PO authorization rule applies, the order cannot proceed until it is authorized (check the exact status names in your release) |
| P2P-03 | Procurement | Order the buyer is not allowed to authorize stays blocked | Buyer | ZPUR_BUYER (customer-defined) | PO above the buyer limit in your SoD matrix | 1 Log in as the test buyer. 2 Try to release and authorize the PO | Release is stopped until the routing template approver authorizes, and the buyer cannot approve their own order, as designed in your SoD matrix |
| P2P-04 | Inventory receipt | Partial receipt against a purchase order | Warehouse operator | ZINV_RECEIVER (customer-defined) | PO line for 100 pcs, receive 60 | 1 Register the receipt of 60 pcs. 2 Check the PO line status. 3 Check where the stock sits | Line shows 60 received, 40 open. Inventory postings follow your configured ownership transfer point |
| P2P-05 | Accounts payable | Supplier invoice matches the purchase order receipt | AP clerk | ZFIN_AP_CLERK (customer-defined) | Receipt from P2P-04, invoice with a 2 percent price difference | 1 Enter the supplier invoice. 2 Match it to the receipt. 3 Record the price difference | Invoice is matched at receipt or line level, and the price difference is shown and posted as configured |
| P2P-06 | Accounts payable | Payment proposal selects only authorized invoices | AP manager | ZFIN_AP_MANAGER (customer-defined) | One authorized and one unauthorized invoice for the same supplier | 1 Generate a payment proposal for the date interval. 2 Check the selection. 3 Process the proposal as in your payment procedure | Only the authorized invoice is selected |
| O2C-01 | Sales | Customer order reservation respects the credit limit | Sales coordinator | ZSAL_COORDINATOR (customer-defined) | Customer close to the credit limit, stocked part available | 1 Enter a customer order line. 2 Reserve the order. 3 Read the credit check message | Reservation follows the credit limit and advance invoice rules configured for the customer |
| INV-01 | Inventory | Stock reservation shows on the part in stock | Planner | ZINV_PLANNER (customer-defined) | Part with two stock locations | 1 Reserve a customer order line. 2 Open the part in stock and check the reservation | Reservation is visible on the stock record and quantity available is reduced |
Execution block, as it looks before the cycle starts
| ID | Actual result | Status | Defect ID | Severity | Tester | Date | Retest | Sign-off |
|---|---|---|---|---|---|---|---|---|
| P2P-01 | Not started | |||||||
| P2P-02 | Not started | |||||||
| P2P-03 | Not started | |||||||
| P2P-04 | Not started | |||||||
| P2P-05 | Not started | |||||||
| P2P-06 | Not started | |||||||
| O2C-01 | Not started | |||||||
| INV-01 | Not started |
Paste into Excel
The block below uses a semicolon as the delimiter. Paste it into column A, then use Data, Text to Columns, Delimited, and tick Semicolon. Add one row per scenario and keep the IDs stable.
ID;Process area;Scenario;Business role;Permission set used;Test data;Steps;Expected result;Actual result;Status;Defect ID;Severity;Tester;Date;Retest;Sign-off
P2P-01;Procurement;Requisition above the authorization rule limit is routed to the approver;Requisitioner, then Department manager;ZREQ_REQUESTER and ZREQ_APPROVER (customer-defined);Requisition for a stocked part, value above the rule limit;1 Create and release the requisition. 2 Check that authorization is required for it. 3 Approver authorizes the requisition lines;Requisition shows as authorized after the approver acts (check the exact status names in your release). A line that still needs authorization cannot be converted to a PO;;Not started;;;;;;
P2P-02;Procurement;Authorized requisition line converts to a purchase order;Buyer;ZPUR_BUYER (customer-defined);Authorized line from P2P-01, supplier with a valid price;1 Convert the requisition line to a purchase order. 2 Release the order;PO is created for the right supplier, quantity and price. If a PO authorization rule applies, the order cannot proceed until it is authorized (check the exact status names in your release);;Not started;;;;;;
P2P-03;Procurement;Order the buyer is not allowed to authorize stays blocked;Buyer;ZPUR_BUYER (customer-defined);PO above the buyer limit in your SoD matrix;1 Log in as the test buyer. 2 Try to release and authorize the PO;Release is stopped until the routing template approver authorizes, and the buyer cannot approve their own order, as designed in your SoD matrix;;Not started;;;;;;
P2P-04;Inventory receipt;Partial receipt against a purchase order;Warehouse operator;ZINV_RECEIVER (customer-defined);PO line for 100 pcs, receive 60;1 Register the receipt of 60 pcs. 2 Check the PO line status. 3 Check where the stock sits;Line shows 60 received, 40 open. Inventory postings follow your configured ownership transfer point;;Not started;;;;;;
P2P-05;Accounts payable;Supplier invoice matches the purchase order receipt;AP clerk;ZFIN_AP_CLERK (customer-defined);Receipt from P2P-04, invoice with a 2 percent price difference;1 Enter the supplier invoice. 2 Match it to the receipt. 3 Record the price difference;Invoice is matched at receipt or line level, and the price difference is shown and posted as configured;;Not started;;;;;;
P2P-06;Accounts payable;Payment proposal selects only authorized invoices;AP manager;ZFIN_AP_MANAGER (customer-defined);One authorized and one unauthorized invoice for the same supplier;1 Generate a payment proposal for the date interval. 2 Check the selection. 3 Process the proposal as in your payment procedure;Only the authorized invoice is selected;;Not started;;;;;;
O2C-01;Sales;Customer order reservation respects the credit limit;Sales coordinator;ZSAL_COORDINATOR (customer-defined);Customer close to the credit limit, stocked part available;1 Enter a customer order line. 2 Reserve the order. 3 Read the credit check message;Reservation follows the credit limit and advance invoice rules configured for the customer;;Not started;;;;;;
INV-01;Inventory;Stock reservation shows on the part in stock;Planner;ZINV_PLANNER (customer-defined);Part with two stock locations;1 Reserve a customer order line. 2 Open the part in stock and check the reservation;Reservation is visible on the stock record and quantity available is reduced;;Not started;;;;;;How do you define defect severity and go/no-go rules for UAT?
Severity must describe the business effect, not the effort to fix, and each level needs a rule that decides what happens at go-live. The values below are starting points to agree with the steering group before cycle one; they are working practice, not an IFS standard.
| Severity | Definition | Rule for go-live |
|---|---|---|
| S1 Blocker | A business process cannot be completed and there is no workaround, or a posting, payment, tax or authorization result is wrong | Must be fixed and retested. Any open S1 means no-go |
| S2 Major | The process completes only through a manual, error-prone or temporary workaround | Fixed, or accepted in writing by the process owner with workaround, owner and fix date. No open S2 in a critical process without that acceptance |
| S3 Minor | Wrong label, layout, report format or message with a trivial workaround | May go live. Logged with a target release |
| S4 Change request | Behaviour matches the agreed design but the user wants something else | Not a defect. Goes to the change backlog and is not counted in exit figures |
Entry and exit criteria
| Gate | Criterion (starting values to agree with the steering group) |
|---|---|
| Cycle entry | Build deployed and smoke-tested; tester accounts exist with the production permission sets; test data loaded and checked; scenarios approved by process owners; defect log open |
| Cycle exit | All critical-process scenarios executed; no open S1; every open S2 has a written decision; every S1 and S2 fix retested; first-pass rate and blocked count reported |
| Go-live recommendation | Two consecutive clean passes of the critical processes in the final cycle; zero open S1; no unaccepted S2; training material updated for each accepted workaround; every process area signed |
| No-go triggers | Any open S1; any unaccepted S2 in a critical process; a critical scenario not executed; a fix delivered without retest; a tester signing off a scenario they did not run |
The go/no-go table is also the agenda of the readiness checkpoint in your governance cadence, where the sponsor sees counts per severity and per process area instead of a percentage of tests done. Exit criteria are easier to agree when they are written into the test strategy: Test Strategy Template (IDK-17) has entry and exit criteria per test cycle, and SAT and ORT Test Script and Sign-off Template (IDK-18) carries the script, the defect log and the signed completion report. The same reasoning applies to the cutover rehearsal: go-live is a load test explains why the go/no-go criteria are written before the rehearsal, not during it.
How do you run an IFS Cloud UAT cycle?
A UAT cycle is a fixed window in which the same scenario list is executed on a stable build, triaged daily and closed with signed evidence. The sequence:
- Check the entry criteria. The build is deployed, testers can log in with the production permission sets, the test data from the tracker exists, and the scenarios are approved. A cycle that starts without this burns its first days on environment defects.
- Assign scenarios by role, not by person. Every row has a named tester and a backup. A scenario nobody owns shows as Not started in the report on day one, which is the point.
- Hold a 30-minute triage every day at the same time. Attendees: test lead, IFS consultant, a developer if CRIMs are involved, and one key user per process. Each new defect is classified as configuration, custom code, data, permission, training or change request, and gets a severity, an owner and a target build.
- Freeze the build between fix drops. Fixes arrive in named drops. A tester retests only against a drop, and the Retest column records which one.
- Retest the fix and the neighbours. Every S1 and S2 fix is retested; scenarios that share the object or permission set with the fix are re-run.
- Collect evidence while testing. Per scenario keep the document numbers created (order, requisition, voucher), a screenshot of the result, the user and permission set, the date and the build.
- Close the cycle with sign-off. The process owner reviews the failed, blocked and deferred rows, accepts or rejects each, and signs the process area. The test lead publishes the exit figures against the criteria above.
For upgrades, add the readiness view from IFS Cloud upgrade readiness and the user-side checks in how to assess whether business users are prepared for an ERP upgrade. Automating the regression part is discussed in Rethinking test automation for IFS Cloud.
Which environment and test data should UAT use, and can you create a test company in UAT?
UAT needs an environment that behaves like production, with data that business users recognise and a company set up the way production will be. A separate test company in the UAT environment is a workable technique for tests that post or delete data, and a weak basis for acceptance of the configuration that the live company will run.
- Company-specific configuration. Authorization rules, routing templates, posting control and ownership transfer points live per company or per part. A test company only proves them if you copy them, so verify what a copy actually carries over before relying on it. Nothing on docs.ifs.com that forbids a test company in UAT was found; this guidance is working practice.
- Test data for IFS-provided environments. An IFS reply on the Community confirms that on-demand environments include generic pre-defined test data and no customer-specific data, see the thread. For a release upgrade, a Community answer describes the upgrade being done in a separate non-production environment with a copy of customer data, see the 24R2 to 26R1 thread.
- Test Data Management. The IFS Lifecycle documentation on docs.ifs.com has a Test Data Management section; check it for the current options, and confirm any licensing with IFS before planning around it.
- Migrated data. If UAT uses migrated data, the quality of the migration decides the quality of the result. See data migration silent killers in FNDMIG and DMM and IFS DMM step by step.
- Personal data. If production copies are used, decide who may see which data before testers get access. No documented masking feature was found, so treat masking as a customer decision.
Write the test data into the tracker row. If the scenario needs "a customer near the credit limit", name the customer ID, so the run can be repeated and the failure reproduced.
What does the IFS Scope Tool give you, and what must you build yourself?
The Scope Tool gives you the process hierarchy down to scenario level, and according to a Community reply it feeds a Test Tracker in which each scenario is one test case. It does not give you the severity rules, the cycle cadence, the permission-set mapping or the sign-off evidence; those come from your project.
| Topic | What the sources state | What you build |
|---|---|---|
| Scenario list | A Community reply says the Scope Tool models business processes to scenario level and drives Test Tracker creation, one scenario per test case, as manual tests and not automated scripts. See the Scope Tool thread. | Review every scenario with its process owner; add integration, authorization and negative scenarios. |
| Tracker format | The same reply mentions scenario sheets, overview sheets and pass/fail colouring. No public docs.ifs.com page with the menu path, column layout or export steps. | Compare the exported file with the 16 columns above; add the missing ones, typically permission set, severity, retest and sign-off. Ask the Solution Architect who maintains your Scope Tool. |
| Upgrade test material | No public statement was found that IFS supplies business test scripts for a customer release upgrade. The Community upgrade thread lists functional, regression, integration and reporting validation, and mentions no IFS test pack. | Derive the upgrade scope from your live processes, your CRIMs and the release notes; own the scenario list. |
| Automation | The IFS Developer Portal lists Script-A-Rest for scripting IFS Cloud functionality through its REST APIs. See IFS Developer Portal. | Decide which regression scenarios deserve scripts; the tracker keeps the manual UAT evidence either way. |
| Defects and sign-off | Not described in the sources reviewed. | Defect log, severity rules, triage cadence, evidence and signatures, as in this article. |
If you want a tool instead of a spreadsheet, the choice is between the Scope Tool export, a spreadsheet like the one above and a third-party test management product. Whatever you choose, keep the same column set, so evidence survives a change of tool.
IFS UAT test tracker: frequently asked questions
What is an IFS UAT test tracker?
An IFS UAT test tracker is a register with one row per business scenario that records who tests it, with which permission set and data, what was expected, what happened, the defect and severity, the retest and the sign-off. In an IFS Cloud project or release upgrade it is the evidence that business users, not consultants, accepted the solution.
Can the IFS Scope Tool generate a test tracker?
According to a reply in the Scope Tool thread on the IFS Community, yes: the Scope Tool drives the creation of Test Trackers in which each scenario becomes one test case, and these are manual test lists, not automated scripts. No public docs.ifs.com page describes the function or its exact output, so ask the IFS Solution Architect who maintains the Scope Tool for your project to export it.
Is it acceptable to create a test company in the IFS Cloud UAT environment?
A test company in UAT is acceptable for isolated or destructive tests, and it is a poor basis for acceptance of company-specific configuration such as authorization rules, posting control and number series. If a test company is created by copying another, verify what the copy carries over before relying on it. Run the critical scenarios in the company that mirrors production.
Who should run UAT in IFS Cloud?
Business key users and expert users run UAT, each logged in with the permission set of the production role they represent. Consultants prepare data, triage defects and fix configuration, but they do not execute or sign off the business scenarios. The process owner signs per process area.
What should block a go-live decision in UAT?
Any open S1 defect, any S2 defect in a critical process without a written acceptance, a critical scenario that was not executed, or a fix delivered without a retest. Agree these rules before the first cycle starts so that the decision is not negotiated under deadline pressure.
Does IFS provide UAT test scripts for an upgrade?
No public statement was found that IFS supplies ready-made business test scripts for a customer release upgrade. A community thread on a 24R2 to 26R1 upgrade describes functional, regression, integration and reporting validation on a separate non-production environment with a copy of customer data and mentions no IFS test pack, so plan to own the scenario list.
Sources
About the author
Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
For the end-to-end project view, see the IFS Cloud ERP implementation guide. To set up a tracker and run UAT cycles on your project, book a 30-minute call.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
- Details
Independent IFS Cloud practice · Implementation
IFS Cloud ERP implementation: what happens, who owns it, and what proof to ask for at each gate
Key takeaways
- An IFS Cloud ERP implementation is a sequence of gated phases: initiate, confirm a prototype, establish the solution, implement (readiness, training, cutover rehearsal) and go live, followed by hypercare. Names vary between IFS and its partners, the gates do not.
- Duration is driven by scope (sites, legal entities, modules), data quality, the number of integrations and how fast the customer can decide. A fixed number of months says little until those four are known.
- Four roles carry the project on the customer side: a steering committee, a product owner, key users and data owners. Without a named data owner, migration stalls, because nobody can approve cleansed records for loading.
- At every gate, ask for evidence you can open: signed test scripts, reconciliation reports, a permission matrix, a cutover plan with a timed rehearsal. A status colour is not evidence.
- Permission sets, segregation of duties and the go-live decision belong on the plan from the prototype phase, not in the final month.
An IFS Cloud ERP implementation takes a customer from an empty or legacy-fed environment to a live system through five gated phases, and it succeeds when each gate is passed on evidence rather than on a progress percentage. This guide describes what each phase contains, which customer roles must be named, which environments you need, and what to request before you agree that a phase is complete. It is written for the person evaluating or planning the project, not for the person configuring it.
1.What does an IFS Cloud ERP implementation consist of?
The IFS implementation method is prototype-driven: the project builds a working prototype early, confirms it against the customer's own processes, and only then builds the full solution. Customer project pages that follow the IFS method, such as the Western University EAM milestone page, list five phases: Initiate, Confirm Prototype, Establish, Implement and Go Live. A thread on the IFS community uses the same sequence and points to the IFS Academy course "IFS Implementation Methodology" for the detail. Partners relabel and subdivide the phases, so take the names as a vocabulary and confirm the exact gates in your contract.
Within those phases the work falls into the same recurring streams: solution design and configuration, data migration, integrations, reporting, testing, security, training and change management, and cutover. Data migration is covered in the IFS Cloud data migration plan, and testing in IFS Cloud testing.
2.What happens in each phase, and what evidence can you ask for?
The table maps each phase to the evidence that proves it is finished. The phase contents follow the IFS method as published on the milestone page above; the evidence column is my own practice, because gate evidence is not prescribed by the method.
| Phase | What happens | Evidence you can ask for |
|---|---|---|
| Initiate | Project plan, governance, roles named, applications installed, scope and legal entities fixed | Signed scope statement, RACI with named people, environment list with owners, decision log opened |
| Confirm Prototype | A prototype is built on your processes and confirmed in workshops; the migration approach is defined | Process list with a prototype walk-through per process, gap list with owner and decision, migration object inventory |
| Establish | Full solution and migration built and verified; solution acceptance testing; training and change material prepared | Executed test scripts with results, defect log by severity, migration load and reconciliation reports, permission matrix |
| Implement | Operational readiness testing, user acceptance testing, end-user training, cutover rehearsals | UAT sign-off per business area, timed cutover rehearsal log, trained-user list, open-defect list with agreed workarounds |
| Go Live | Final data load, cutover, go/no-go decision, switch to production | Cutover runbook with actual timings, final reconciliation, signed go/no-go with named approvers, rollback criteria |
| Hypercare | Heightened support after go-live while the business runs real volumes through the system | Issue log with age, first period-end close completed, handover to a support owner |
Hypercare is not a named phase on the published milestone page; its length and scope come from the partner contract, so check what it covers before you sign.
To keep the evidence column honest, the Qualification Gate Checklists template (IDK-08) turns it into five gate checklists, each item needing evidence a third party can inspect. It is one of 24 templates grouped by the same five phases in the Implementation Docs kit.
3.Which project roles must the customer name?
The customer must name four roles before the prototype phase starts, because each one holds a decision the implementation partner cannot make.
- Steering committee. Approves scope changes, budget and the go/no-go. It needs an executive who can overrule a department.
- Product owner. Decides process questions between workshops. Without this person, open design questions queue until the next steering meeting.
- Key users. Run the prototype workshops, write and execute test scripts, and train colleagues. They need protected time in their calendar, not goodwill.
- Data owners. One named person per data domain (customers, suppliers, parts, prices, open orders) who approves the cleansed data before it is loaded. The partner can extract and transform data, but it cannot declare a supplier record correct.
The data side has its own role, described in the role of the IFS Cloud data migration manager. For the delivery side of the table, see IFS Cloud implementation consultants.
4.Which environments do you need?
You need at least one environment for building and testing and one for production, and in practice a separate environment for user acceptance testing so that configuration is not changing while users test. The exact environment set, who provisions it and what it costs are defined in your IFS cloud agreement, so ask for the list with purpose, owner and refresh policy during Initiate.
After go-live the environments serve the release cycle. IFS community answers from a 2026 service webinar state that new releases can be deployed to test environments to validate them against your configuration and customisations, that each release stays supported for approximately two years from general availability, and that temporary test environments created on demand are not meant to hold customer data permanently (IFS community Q&A). The practical consequence: keep a test environment that mirrors production configuration, and read IFS Cloud upgrade readiness before your first release update.
5.How should data migration be planned?
Data migration is planned from the Confirm Prototype phase, where the migration approach is defined, and it is rehearsed repeatedly before go-live. Each migration object needs an owner, a source, a transformation rule, a load method and a reconciliation check that compares counts and values before and after the load.
Two failure patterns recur. First, load runs that succeed technically while the data is wrong, because nobody reconciled it; this is the subject of silent killers in FNDMIG and DMM. Second, cleansing left to the last weeks, because it needs business decisions that take calendar time. A practical walk-through of the tool is in IFS DMM step by step.
6.What does testing and UAT need to prove?
Testing proves that the configured system supports the processes the business agreed in the prototype, using migrated data and the real integrations. The method places solution acceptance testing in Establish and operational readiness testing in Implement. User acceptance testing is run by the key users, on scripts traced to business processes, and ends with a signed result per business area.
A tracker that shows script, owner, status, defect and retest result is the minimum record; a ready-made version is described in the UAT test tracker template, and the approach in UAT in IFS Cloud. If your project replaces Crystal Reports output, add report acceptance to the scope early: moving from Crystal Reports to Report Studio shows what has to be rebuilt and re-checked.
7.When do permission sets and segregation of duties come in?
Permission sets are designed during Establish, from a role-to-process matrix, and they are tested in UAT with real user profiles, not with an administrator account. Access in the IFS Cloud web client is granted through permission sets that contain projections, as the IFS community thread on Aurena access permission sets describes, so a role that "works" for the consultant may expose more than intended to an ordinary user.
Write the conflicting duty pairs down (for example, creating a supplier and approving a payment to that supplier) and test them with the finance owner present. The method is in permission sets and segregation of duties; the rules a business agrees before configuration are in the enterprise book of rules.
8.What governance cadence keeps the project honest?
A governance cadence is a fixed rhythm of meetings that each produce a decision list: a weekly working session between the product owner and the partner lead, a regular steering committee, and a gate review at the end of every phase. The rhythm matters more than the frequency. Decisions that need a steering committee must reach one within days, otherwise the plan slips quietly while the status stays green. The full model is in governance cadence.
9.How is cutover and go-live run?
Cutover is a written runbook of timed steps (freeze legacy transactions, extract, load, reconcile, switch integrations, open the system) that is rehearsed end to end with real timings: rehearse the cutover at least once before go-live, and repeat until the reconciliation results are clean. The go/no-go meeting reviews open defects, reconciliation results, user readiness and the rollback criteria, and the decision is recorded with the name of each approver.
After go-live, hypercare covers the first real business cycles. The first period-end close is the best test of whether finance, supply chain and reporting work together, so keep the project team in place until it is completed. If you want purchasing exceptions watched from the first day of hypercare without touching IFS, the SCM Automation Pack reads IFS over read-only OData, creates no objects in IFS and starts with an observation week in which nobody receives a message. Projects with several sites add a rollout sequence on top of this; see multi-site IFS Cloud implementation.
10.Why do IFS Cloud implementations fail?
Implementations fail when decisions, data or testing time are missing, and the system itself is rarely the cause. The recurring patterns are listed below with the early signal that shows each one.
- No empowered product owner: the design-issue log grows between workshops.
- Data without owners: cleansing tasks have no named approver, and load rehearsals keep failing reconciliation.
- Key users without time: test scripts are written by the partner and executed late.
- Scope growing through gaps: each gap is accepted in a workshop and none is priced or decided at steering level.
- Security left to the end: permission sets are first tested with real users in UAT, when little time remains to change them.
- Go-live date fixed before the evidence exists: the date drives the plan instead of the gate results.
Two longer treatments are why IFS Cloud implementations fail and the brutal truth about IFS implementations.
11.What does a realistic planning checklist look like?
Use this list before you sign a plan or approve a phase. Each item is answered with a document, a name or a date.
- Scope in writing. Sites, legal entities, modules, integrations and reports, with what is explicitly out.
- Named roles. Steering members, product owner, key users with their allocated time, and one data owner per domain.
- Phase gates with evidence. Each gate lists the artefacts from the table in section 2.
- Environment plan. Purpose, owner and refresh rule for every environment, including the UAT environment.
- Migration inventory. Every object with source, owner, transformation, load method and reconciliation check.
- Test strategy. Who writes scripts, who executes them, how defects are classified and what blocks go-live.
- Permission matrix. Roles to permission sets to processes, with the conflicting duty pairs listed.
- Governance calendar. Steering, working sessions and gate reviews on the calendar from day one.
- Cutover runbook and rehearsals. Timed rehearsals, repeated until the reconciliation results are clean, before the go/no-go meeting.
- Hypercare terms. Length, scope, response times and the named owner who takes over afterwards.
- Release plan. How the first release update after go-live will be tested.
If you want an outside review of a plan, a vendor proposal or a project already in trouble, see services for IFS Cloud.
12.Frequently asked questions
How long does an IFS Cloud ERP implementation take?
The duration of an IFS Cloud ERP implementation depends on scope, data quality, the number of integrations and the speed of customer decisions, so no single figure is reliable. Plan from the scope: count sites, legal entities and migration objects, then ask the partner to show the duration of each phase and the assumptions behind it.
What are the phases of an IFS Cloud implementation?
The IFS implementation method is commonly described in five phases: Initiate, Confirm Prototype, Establish, Implement and Go Live. Projects usually add a hypercare stage after go-live. Partners may use different labels, so confirm the gates and their evidence in the contract.
Who should be on the customer side of an IFS Cloud project?
An IFS Cloud project needs a steering committee, a product owner, key users with protected time and one data owner per data domain. These four roles make the decisions that the implementation partner cannot make: scope, process design, test acceptance and data approval.
What should be tested before IFS Cloud go-live?
Before an IFS Cloud go-live, test the agreed business processes with migrated data and real integrations, run user acceptance testing with signed results per business area, test permission sets with ordinary user profiles, and rehearse the cutover with recorded timings.
When should permission sets and segregation of duties be designed in an IFS Cloud implementation?
Design IFS Cloud permission sets during the Establish phase from a role-to-process matrix, list the conflicting duty pairs, and test them in UAT with real user profiles. Leaving security until the final weeks leaves no time to change roles after testing.
13.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Check your plan before the first gate
Send me your project plan, partner proposal or current phase status. I will mark which gates have no evidence behind them and which roles are still unnamed.
- Details
Independent IFS Cloud practice · Reporting and analysis
Lobbies and custom dashboards in IFS Cloud: what a lobby can show, who builds it, and where it fits
In my opinion a lobby is the IFS Cloud answer to the request for a dashboard. This article explains how a lobby page, its elements and its data sources fit together, what a lobby element can display, what permission set building one needs, what personalisation the guide describes, and how a lobby differs from a Quick Report or a Crystal report. The rollout section is my own practice.
Key takeaways
- A lobby page is built from three parts: the page, its lobby elements and the data sources behind them. In the 25R2 user guide a page holds one or more elements, each linked to a data source, with two documented exceptions.
- The 25R1 technical documentation describes the Lobbies page as a tool for developers and super users, and says creating or modifying a lobby needs an appropriate permission set. The 25R2 user guide also describes a Personalize function for personal elements.
- A personal element can contain text, a web link, a saved search or a Quick Report, according to the 25R2 user guide.
- In my view a lobby says where to look first, a Quick Report gives a list on demand, and a Crystal report produces a formatted document.
1.What is a lobby in IFS Cloud?
According to the IFS Cloud 25R2 user guide, lobby pages gather data from IFS Cloud and from external data sources into a snapshot of current operations. The guide says you can see what to focus on and where the exceptions are. The building blocks of a page are called lobby elements.
A page contains one or more elements, and each element is linked to a data source. Two exceptions are named: the Links List element may use several data sources, and Image/Text uses none. A click on some elements opens a page chosen by the administrator, inside or outside IFS Cloud.
The 25R1 technical documentation says the Lobbies page lists lobby pages as tiles, with a search and a client type filter. It calls the page a tool for developers and super users, and points end users to "My Lobbies" under My Administration. It places the Element Designer and Data Source Designer in the navigator under Solution Manager, Configuration, Lobby.
2.What can a lobby element show, and how is it built?
The 25R2 user guide names thirteen element types on its Lobby Element Types page and lists fourteen names on its Lobby Elements page, where Line Chart and Image appear and the first page omits them. The 24R2 Element Designer page gives the number of types as 15, so the count differs between pages and releases. The table below follows the thirteen types of the Lobby Element Types page, with only the behaviour that the documentation states.
| Element | Documented purpose |
|---|---|
| Counter | A count of specific events, actions or quantities in the system. |
| List | Selected columns of a data source in table form, with a click on a row opening a page if navigation is configured. The page notes two views. |
| Bar Chart, Pie Chart, Funnel Chart | The Pie Chart shows shares and percentages, and the Funnel Chart shows stages. Hovering shows the column name and value (Bar), the segment name and percentage (Pie), or the stage name and number of records (Funnel). |
| Matrix, Analog Gauge, State Gauge | Navigation is documented for these elements: a click opens a page when the administrator has configured navigation properties (the Analog Gauge has a navigation link). |
| Links List, Image/Text | The Links List may be associated with several data sources, and Image/Text relies on no data source. Navigation targets are pages defined by the administrator, inside or outside IFS Cloud. |
| Radar Chart | Named in the 25R2 element type list. The pages I read give no further description. |
| Power BI | A Power BI report, dashboard tile or visuals. The available functions depend on the configuration by the application developer. |
| Web Content | An IFS Cloud page or another web page shown inside the lobby, working like a separate browser window. |
The data comes from a data source, and the Data Source Designer documentation (24R2) names two types. A SQL data source is based on a database query. A projection data source is based on a projection, and query projections listed on the Queries page can be used next to existing system projections. The Preview runs the query, so you can confirm the expected data is returned before an element depends on it.
The 24R2 Element Designer page lists four sections that are shared by all element types: Element Layout (name, title, width, height, color style), Element Preview, Navigation and Information. The designer also offers Used In, which shows the pages where an element is used, Export and Import through an xml file, translations, and the Protect, Protected and Edit Anyway controls. I read their purpose as guarding against accidental edits, which the page summary I read does not state.
Page parameters are set up by an administrator at the data source level, according to the 25R2 user guide. They appear as input fields in the Page Parameter slide-out, and clicking OK refreshes the elements that depend on them.
3.How does a lobby differ from a Quick Report or a Crystal report?
The IFS documentation I read does not define "dashboard" as a product term and does not compare lobbies with reports, so the comparison below is my own reading. In this article a dashboard means a lobby page.
| Tool | Documented | My view of the job |
|---|---|---|
| Lobby | A snapshot of operations built from elements and data sources. | The first screen of a role: counts, short lists and charts. |
| Quick Report | Foundation1 guide: a lightweight ad hoc report, not designed for large data volumes or advanced analytics. Types include SQL Statement, Crystal Report and Query Builder. | The detail list behind a number. The user guide lets you add a generated Quick Report to a personal element. |
| Crystal report | Foundation1: a type that a Quick Report can have. Release availability is covered in a separate article. | A formatted document with a fixed layout. See Crystal Reports in IFS Cloud for its status. |
The Quick Report description comes from Foundation1 documentation, not a 25R2 or 26R1 page, so confirm it against your release.
4.What are the limits and pitfalls of lobbies?
- Permission sets - the 24R1 permission set page states that Lobby Pages can only be modified on permission sets with the Custom delivery type, which concerns which permission sets can have their lobby access edited and not who may build a lobby. Granting access to a page also grants access to its data sources and elements, and you deselect those you do not want to expose.
- Navigation is configuration - a click leads to a page when the administrator has configured navigation properties for that element.
- Personal elements have a defined content list - text, web link, saved search and Quick Report. The guide does not say that a personal element can use an arbitrary data source, so I would not promise that to users.
- Widgets - administrators can add Home Widgets to a lobby page, and users can change widget settings, which are saved to their profile.
- Guidelines - the technical documentation lists a Lobby Performance Guideline and a Lobby Navigation Guideline. I did not read them, so read them before building heavy queries.
A further pitfall is a number nobody owns. A counter of overdue items is decoration until a named person is expected to act on it, which is the argument of exception routing instead of reporting. A correct data source can still feed a misleading metric, as in the on-time delivery metric that lies.
5.How do you roll out a first lobby as a quick win?
The rollout below is my practice, not an IFS procedure. In my view it fits the quick-win band of strategic IFS Cloud customization, because a lobby is built in the designers described above. A SQL data source is a database query, so it needs someone who writes SQL.
- Start from the questions of one role. Ask a buyer, planner or warehouse lead which three questions they ask the system first, and build around those answers.
- Choose the element by the question. A counter gives a count, a list names the records, a chart shows the split.
- Build and preview the data source first. Test it in the Preview with a realistic filter. An example is a count of items below their reorder point, see reorder point planning.
- Configure navigation for each element so that every number leads to the page where someone acts.
- Grant access deliberately. Adjust the permission set, remembering that a page brings its data sources and elements with it.
- Let users personalise within the documented limits. Show them Add My Element for a saved search or Quick Report they already use.
- Review after a few weeks. Ask which elements were used and remove the rest. Where a number needs a reaction, move it out of the lobby, for example into IFS Cloud workflows, and weigh it against the cost of manual monitoring.
Primary sources: Using Lobby Page (25R2) and Lobby Element Types (25R2). I did not read a 26R1 lobby page, so check the release you run.
6.Frequently asked questions
What is a lobby in IFS Cloud?
A lobby is a page that gathers data from IFS Cloud and external data sources into an overview of current operations. It is built from lobby elements such as counters, lists and charts, and each element is linked to a data source, with two documented exceptions.
Who can build a lobby in IFS Cloud?
The 25R1 technical documentation describes the Lobbies page as a tool for developers and super users, and says that creating or modifying a lobby requires an appropriate permission set. The 24R1 permission set documentation says that granting access to a lobby page also grants access to its data sources and elements. The documentation I read does not name a role that may build a lobby beyond this.
Can users personalise a lobby page?
The 25R2 user guide describes a Personalize function with Add My Element, Edit / Delete My Elements and Show/Hide My Elements. A personal element can contain text, a web link, a saved search or a Quick Report. The guide does not state which roles or permission sets are required.
Is a lobby a replacement for a Quick Report or a Crystal report?
The documentation does not compare a lobby with a Quick Report or a Crystal report. In my view a lobby gives an overview and a starting point, a Quick Report gives an on-demand list, and a Crystal report gives a formatted document. The user guide lets you add a generated Quick Report to a personal lobby element, so the two can work together.
7.About the author
Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Decide what the first screen of each role should say
Tell me which three questions a planner, buyer or warehouse lead asks first. On a 30-minute fit call we can sketch a first lobby: elements, data sources, click-through and permission set.