I seem to have been getting a lot of interesting questions recently!    In this case, a customer has setup their instance such that the default ADMIN user is not to be used routinely (which is great and considered best-practise) but did not want to disable the ADMIN user completely.  They do however want to get an alert whenever the ADMIN user logs in, to ensure no-one is using it for any reason.

There are various possible ways to achieve this, but the obvious choice within X3 would be to use a Workflow rule…

The first port of call was to look at the provided “LOGON” workflow rule.   This does work OK, but during testing this option found a few issues which made it not entirely satisfactory:

• Workflow rules run in the context of a folder, so needs to be setup for every folder.
• The rule is not triggered when the user logs in to X3 and sits on the home page, but only when the user launches then exits a classic function.
• On the customer system there were a lot of alerts generated which did not seem to be due to interactive users (It is still not clear why this is happening at the time of writing)

The next option is to see if it is possible to setup a custom workflow rule to do a better job.   I have documented below a proof-of-concept that I think fits the bill for the customer requirements outlined above.  For my testing I setup a workflow rule to trigger when the user MIKE is logged in (as I am using ADMIN all over the place in my test system!).   The concept is to use the X3.ASYSSMINTERN as the trigger, as this table stores all connected user details as soon as they login – with the record being deleted when they logout.   To do this I need to use a Manual Workflow which needs to be scheduled to run via the batch server as a Recurring task.     

NOTE: this concept does give a small window of opportunity to “miss” a user login, but this can be mitigated by the fact that a user would have to login, then do something and be able to logout within one minute, plus they would have to get lucky and miss the batch run kicking off (if you run the batch task every minute).  As an alternative approach, I did consider creating a view which combines all folders ALOGIN tables into one and use that for my Workflow rule but didn’t test that out as yet (the selection criteria would also be a bit trickier to work out for this alternative).

Steps to take

Login to X3

Login as ADMIN user and connect to SEED folder

Create new Activity code

Create new Data Model

https://online-help.sageerpx3.com/erp/12/staticpost/data-models/

Although I am connected to SEED folder, I can pick the ASYSSMINTERN from X3 folder

Create new workflow rule

https://online-help.sageerpx3.com/erp/12/staticpost/workflow-rules/

I decided to go a little way past the absolute simplest, as thought it would be good to pick up some fields from the ASYSSMINTERN table in the alert email.   If you want the absolute simplest option, you can remove the Trigger tracking and milestone setup.

Notice the “Conditions” is where I am hardcoding the MIKE user to trigger the alert, and for now have also hardcoded the recipient as the ADMIN user

Save, then validate

Note: you will get a separate email for every Adonix session the user has open at the time the workflow is triggered, e.g. if the user logs in and launches a classic function, you will get two separate emails.  You could use the Regrouping option if you only want one email.

Test the workflow

Login as user MIKE and check there is at least one record in the X3. ASYSSMINTERN table.

Run the workflow manually to test.

Check an email(s) is generated as expected.

As we can see, I have two emails – this is because in my test I launched a classic function so have two entries in the X3.ASYSSMINTERN table. 

(Optional) Check the Workflow history table.

Can use the SQL below:

select N.CHRONO_0, N.EMETTEUR_0, N.CODWRK_0,  N.DEST_0, N.DATENV_0, N.TIMENV_0, N.TEXSUI_0, M.TEXTE_0,VALCTX1_0,VALCTX2_0,VALCTX3_0
from SEED.AWRKHISSUI as N
       full outer join SEED.AWRKHISMES as M on N.CHRONO_0 = M.CHRONO_0
order by N.CREDATTIM_0 desc

Setup Recurring task

https://online-help.sageerpx3.com/erp/12/staticpost/recurring-task-management/

Configure the recurring task as suits your business needs.

Conclusion

There are additional steps that could be taken to refine and improve this process, such as setting up assignment rules for who gets notified, adding other tables to the data model to get more useful data in the notification email and maybe even use the signature mechanism to allow the administrator to reply and kill the session immediately. 

For now though, I hope these steps have given you one basic approach to generate an alert whenever a particular user logs in to your X3 system.

As always let me know in the comments section below if you find this document useful.