Not that I'm aware of though it's very doable with custom programming, a "mod" as we say. If you don't mind me asking, what task / screen did you want to limit to 1 instance?

Sure.  It's not a stock task.  It's a task in a fully integrated 3rd party module by ROI Consulting called In-Synch, which synchronizes Sage and remote target, like online stores, at or near real-time. 

Its sync task works very well.  The caveat is that only one instance of it at any given time should exist.  So when multiple instances of the sync task are unknowingly started by different users , an unintended/unexpected result could happen.  Since a fix by the developer is in a distant future, I was looking for a temporary patch to mitigate the immediate risk.

what mod / custom programming were you referring?   It's easy to do this in BOI by checking SY_Console in advance, though that's not the most elegant or user friendly....so I was hoping for more integrated ways.  But I'm all ears to any ideas!

By custom program I mean a new one that could be created in ProvideX the native language of Sage 100. You need a master developer (MD) / development partner (DP) for that. If it was a stock program, which I assumed to be the case, overriding that with code that first pre-checks for existing instances of the associated xx_UI.pvc program already being loaded would be my own approach. Checking Sy_Console is not a bad way (we do this in some of our projects anyway) but another is to maintain a custom table and another is a scheme akin to not allowing P/O Options to be opened twice (like you mentioned). None of the approaches would use BOI though.

Having said all that, now I know it's ROI / In-Synch, let me start by saying they are actually a very well known 3rd party and I have known their developers (they do both ProvideX and .NET) for a long time and I have a many good things to say about them. For dealing with not allowing multiple instances of their sync task to run, ideally they add that checking themselves. But since that's in the distant future like you said, depending on how their task is actually launched; (a) standard task run under the Launcher OR (b) runs from the outside (a couple of ways to do that actually), possibly there is another way but it would take some research to know for sure. I'll send you a message via the SageCity chat / message interface.

Thanks for your input!   I've only touched NOMADS/ProvideX a little about 15 years ago so I'm a novice in ProvideX at best. 

By the way, after reading your response, I realized that my original response might have been poorly written so I updated it to avoid any room for it to be construed in an unintended way.  ROI guys are great to work with by the way.  It's the unfortunate reality that any fix to a software won't come overnight, while the users easily forget the most important topic addressed in a meeting yesterday.  

As for how the task is run, it's started from a launcher just like any standard tasks.  

Like Alnoor said, ideally, they would check it in their program. There are a couple ways you may be able to implement something without putting a lot of effort into it though. I don't know enough about the target program to tell you which way is best but if it is launched off the launcher and spawns a pvxwin32.exe program, then you might check to see if the panel can be opened in Customizer, if it can, you can check to see if you can attach a UI Post Load script if you are on version 2015+. In the post load script, you would check SY_Console for another instance and if found, display a message to the user that it is already running and end it.

The other approach, if you are familiar with VBScript would be to create a custom link on the launcher to a .vbs file that would check SY_Console and if another instance is found, display a message to the user and don't launch the task, if it isn't already running, then you will need to find out whether you can start their task the traditional way with a UI object on framework level or if you have to start it the old legacy way.

Thanks David!

The 1st approach unfortunately won't work since the task's UI isn't customizable.  Its sync routine also starts immediately without a user input so even if we could use Post Load event, some data would have been processed by the time the user gets to close the task. 

The 2nd idea is very similar to my original idea of using BOI but simpler.  (Frankly I don't even know why I thought it "had" to be done in BOI).  Even though that still can't prevent a user with enough permissions from launching the task from the module menu or other things like favorite or shortcut, maybe reworking the permissions schema and limit the number of authorized users to a very small  number, and training them might have to be the easiest patch.  Thanks again!!