[{"data":1,"prerenderedAt":19},["ShallowReactive",2],{"case-study-sage-x3-push-notifications":3},{"slug":4,"title":5,"description":6,"industry":7,"region":8,"stack":9,"role":15,"date":16,"seoTitle":17,"html":18},"sage-x3-push-notifications","How we added push notifications to field apps connected to Sage X3 V12","Sage X3 V12 can't send push notifications on its own. We built a small middleware so GCC drivers get order alerts without loading the ERP.","Gas and distribution (field operations)","GCC",[10,11,12,13,14],"Sage X3 V12","Node.js","Firebase Cloud Messaging","REST","Android","Solucrew designed and built the notification middleware and implemented push notifications in the Android app.","2026-10-22","Sage X3 V12 Push Notifications for Field Apps | Solucrew","\u003Ch2>The challenge\u003C\u002Fh2>\n\u003Cp>At a gas and distribution company in the GCC, drivers weren't being notified when an order was assigned to them. The field app was connected to Sage X3 V12, and the orders started in the ERP, so drivers only found out about new work when they checked the app themselves. The company needed push notifications for drivers, plus other events that start in the ERP, such as an order cancelled or an approval requested.\u003C\u002Fp>\n\u003Cp>Sage X3 V12 couldn't send them itself. Firebase's current server-side authentication isn't something X3 V12 can run, and the older approach that used to work no longer applies.\u003C\u002Fp>\n\u003Cp>Three more constraints shaped the design:\u003C\u002Fp>\n\u003Cul>\u003Cli>The X3 team wanted minimal interaction with X3 and no extra load on it.\u003C\u002Fli>\u003Cli>More than five apps connect to the ERP, and each user should only receive what's meant for them, in the right app.\u003C\u002Fli>\u003Cli>Users already exist in X3 and log in through it, so we didn't want to build a second identity system.\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2>The solution\u003C\u002Fh2>\n\u003Cp>Instead of forcing the ERP to do something it can't, we put a thin middleware layer next to it. We built the middleware and implemented the notification handling in the Android app. The middleware has two REST endpoints:\u003C\u002Fp>\n\u003Col>\u003Cli>\u003Cstrong>An event endpoint for Sage X3.\u003C\u002Fstrong> X3 makes one simple call when something happens. No Firebase code on the ERP side, and almost no extra load on it. The client's X3 team added the call on the ERP side; we built the middleware and the app.\u003C\u002Fli>\u003Cli>\u003Cstrong>A registration endpoint for the apps.\u003C\u002Fstrong> After login, the app registers the device's Firebase token for that user.\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>When an event arrives, the middleware finds the devices registered for that user and sends the push through Firebase.\u003C\u002Fp>\n\u003Ch2>Design decisions\u003C\u002Fh2>\n\u003Cul>\u003Cli>\u003Cstrong>Keep the ERP boring.\u003C\u002Fstrong> X3 only makes a simple call and never touches Firebase.\u003C\u002Fli>\u003Cli>\u003Cstrong>Reuse the identity the company already has.\u003C\u002Fstrong> Users are matched to devices through their X3 login, not through a new account system.\u003C\u002Fli>\u003Cli>\u003Cstrong>Two sources of events.\u003C\u002Fstrong> Apps tell the middleware after a successful action in X3, and X3 sends events directly for cases where the ERP is the only sender.\u003C\u002Fli>\u003Cli>\u003Cstrong>Several apps, one Firebase project.\u003C\u002Fstrong> The middleware keeps each app's notifications separate.\u003C\u002Fli>\u003Cli>\u003Cstrong>Small surface area.\u003C\u002Fstrong> REST APIs only, with no admin portal to maintain.\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2>Outcome\u003C\u002Fh2>\n\u003Cp>Drivers now receive a push notification when an order is assigned to them, so they no longer have to check the app to find out about new work. The problem that started the project is solved, and X3 still only makes one simple call.\u003C\u002Fp>\n\u003Cp>We also maintain the middleware and the app, including monitoring and updates.\u003C\u002Fp>\n\u003Ch2>What we'd tell anyone with a similar ERP\u003C\u002Fh2>\n\u003Cp>When a legacy system can't do something, don't fight it. Put a small, well-defined layer next to it and keep the ERP boring.\u003C\u002Fp>\n\u003Ch2>Who this fits\u003C\u002Fh2>\n\u003Cp>Operations and IT teams whose field apps depend on an ERP, and software vendors whose ERP-connected apps need real-time alerts.\u003C\u002Fp>",1792938237650]