COINS continually makes changes to improve the performance of the software. Part of this drive is to remove the need for repetitive reads on data that is rarely changed.
This means that there are some types of data which are read once, on start up, and cached for use by the system. Changing this data may therefore result in the change NOT being picked up until after the system is re-started.
This includes:
Fix Installation.
Update of any COINS Vault settings.
Update of any System Module parameters (including PM Parameters).
System Module Configuration (e.g Terminology, Field Access, Global Search).
Module Essential Parameter Configuration.
It may seem that the configuration change that you have made could not affect particular processes, and that may be true, but the only safe best practice advice is to restart all process after making any configuration change.
⚠️Important: We always recommend that changes to any System Configuration should not be undertaken on a LIVE environment during normal working hours and that any change should be fully tested on a Non-Live Environment prior to being implemented on Live.
📌Note: If your environment is hosted by Access Coins, you cannot restart processes yourself. After making a configuration change that requires a restart, raise a support ticket asking for a process restart on your environment.
Include the type of configuration change made and the date it was saved. The hosting team will restart the relevant processes and confirm when it is complete.
My change isn't taking effect
If a configuration change you have made does not appear to have had any effect, the most likely cause is that the affected processes have not been restarted since the change was saved. COINS ERP+ reads certain types of configuration once at startup and caches the values — changes to these are not picked up until the system is restarted.
Use the table below to identify whether your symptom is caused by a cached configuration that requires a restart:
Symptom | Configuration type requiring restart |
Installed a fix but the issue persists or the fix does not appear active | Fix installation — restart required after every fix installation. |
Changed a parameter but the system is still behaving the same way | System Module parameter or Module Essential Parameter — restart required after saving. |
Changed Field Access settings but users can still see or edit a field | System Module Configuration (Field Access) — restart required after saving. |
Updated Terminology but the old labels are still showing in the system | System Module Configuration (Terminology) — restart required after saving. |
Changed Global Search settings but search results have not updated | System Module Configuration (Global Search) — restart required after saving. |
Updated COINS Vault settings but the change has not taken effect | COINS Vault — restart required after saving. |
If your symptom matches one of the above, follow the restart guidance in the next section. If the change still has no effect after a full restart, raise a support ticket.
How to restart the system
The steps below apply to on-premise and self-managed environments. If your environment is hosted by Access Coins, raise a support ticket instead — see the note above.
Refresh the application server agents — go to System, then System Setup, then Application Server. Select each server agent and click Refresh.
Stop and start all Background Processes.
Stop and start all ESB Processes.
Stop and start all COINS Analytics Extract Processes.
Stop and start MS Graph and MS Exchange Replication.
Stop and start the report agents:
Choose Generator Status from the Report Status Options menu.
Click Open folder, untick the On box, and click Save.
Wait for all the processes to complete and quit. The number of report agents shown should reduce to zero.
Start the agents by ticking On.
Only if a report agent fails to stop in a timely manner then go to disconnecting it.
Data not appearing in a workbench or dropdown
If data — such as a supplier, invoice, cost code or lookup value — is not appearing in a workbench, dropdown or enquiry screen after it has been set up, work through the following checks.
Check whether a restart is needed
Lookups and dropdown values are cached on startup. If a new value was added after the last restart, it may not appear until a restart is performed. Check whether your change matches any of the symptom types in the table above — if it does, follow the restart steps or raise a support ticket if hosted.
Check whether supporting records exist in the affected KCO
In a multi-company setup, each KCO maintains its own configuration records. If a dropdown or workbench is missing values that are present in another KCO, the supporting records may not have been created in the affected KCO. Common examples include sectors, tax codes, country fields, cost types, and analysis categories.
Open the affected KCO and navigate to the relevant setup area (for example, the sector or tax code maintenance screen).
Check whether the expected values exist. If they do not, add them or copy the configuration from the working KCO.
Restart processes after adding supporting records if the value type requires a restart — see the table above for guidance.
Check active filters on the screen
Many workbenches and enquiry screens retain active filters between sessions. If expected records are not visible, check for any active status, date range or type filters that may be excluding them. Clear all filters and refresh the screen to confirm whether the data is present.
📌Note: If data is genuinely missing (not filtered) and the supporting configuration exists and a restart has been performed, raise a support ticket. Include the screen name, the value that is missing, the KCO, and whether the value appears correctly in any other KCO or environment.
Field access — fields hidden or read-only after a configuration change
If a field that was previously visible or editable has become hidden or read-only after a configuration change, the most likely cause is a Field Access Maintenance setting applied at the system module or user group level.
Go to System, then System Setup, then System Module Configuration.
Select the relevant module and open Field Access Maintenance.
Locate the field and confirm its access level — Hidden, Read Only, or Amendable.
Update the field access level as required and save.
Restart the system for the change to take effect — see How to restart the system above.
If the field is hidden for a specific user but not others, the restriction may be applied at the user group level rather than the system level. See How Function Access Works for guidance on checking and updating user-level and group-level access settings.
Work email field locked after linking to a system user ID
If a field shows an access level of Update or Update (Mandatory) in Field Access Maintenance, but the user still cannot amend it, the field may be hard-coded and locked as a security measure rather than restricted by configuration. This applies to the work email address field once an employee record is linked to a System User ID — at that point, the field can no longer be amended by the employee, regardless of their Field Access Maintenance or Group Field Access settings.
Confirm whether the affected employee record is linked to a System User ID.
If it is, do not continue troubleshooting through Field Access Maintenance or Group Field Access for this field — those settings cannot override the lock.
To update the email address for a linked user, go to Systems, then User Maintenance, and amend the email address there. This automatically updates the corresponding HR record.
Alternatively, update the email address directly in HR.
⚠️Important: Only a user with administrator privileges can update the email address for a linked user. Regular employees cannot amend this field themselves, even with Update access in Field Access Maintenance.
📌Note: This lock is deliberate and separate from the field access checks earlier in this article. It will not be resolved by restarting the system, re-running Group Field Access, or adjusting Company/KCO-level access rows.
Diagnose parameter differences between KCOs
If functionality works correctly in one KCO but not another despite similar settings, a parameter or configuration mismatch is the most likely cause. Use the table below to identify the relevant area to check, then follow the steps to compare and reconcile the parameters.
Symptom | What to check |
Workflow trigger fires in one KCO but not another | Compare CDC trigger settings and workflow configurations in both KCOs. Verify that event triggers and filter conditions are identical. |
Order routed to the wrong approval level | Check buyer limit thresholds and approval level settings in the affected KCO. A buyer limit lower than the order value forces routing to a higher approval level. |
Payment transactions routing to the wrong method | Open the batch configuration in the affected KCO and confirm the payment method (BACS or Cheque) is set correctly. Also verify the supplier payment method setting. |
Report option or field not displaying | Confirm that required supporting records — such as sectors, tax codes, or country fields — are populated in the affected KCO. |
User cannot access a function or menu item | Compare User Function Access and Menu Item Security settings between KCOs to identify missing permissions in the affected KCO. |
To compare and update parameters:
Identify the parameter or configuration area causing the issue using the table above.
Go to the relevant module in the KCO where the functionality works correctly and note the parameter values.
Go to the same module in the affected KCO and compare the values.
Update any values in the affected KCO to match those in the working KCO.
Restart all processes in the affected KCO after saving changes — see Guidance for restarting the system above.
⚠️ Important: Always test configuration changes on a non-live environment before applying them to LIVE.
Raise a support ticket
Raise a support ticket if:
Your environment is hosted and requires a process restart after a configuration change.
A configuration change has no effect after a full restart has been performed.
Data is missing from a workbench or dropdown and is not resolved by a restart or checking supporting records.
A field remains hidden or read-only after updating Field Access Maintenance and restarting.
Include the type of configuration change made, the date it was saved, whether your environment is hosted or on-premise, and a description of the symptom you are seeing after the restart.