I see.
There are 3 types of logins into Method:
(1) Normal login (login.aspx) - intended purpose is for staff in the office.
(2) Mobile login (mobile.aspx) - intended purpose is to serve up mobile-optimized pages for staff in the field.
(3) Portal login (thirdpartyportal.aspx) - intended purpose is to give "My Account" access to customers or partners.
Those are the intended purposes. Of course, everything is flexible, so you're able to create variations on the intended purpose, as long as we've provisioned for it.
The portals were never designed to host mobile pages, or inject the extra portal security layer onto the mobile screen. The outer portal frames themselves aren't mobile-optimized, so even if we did have mobile optimized pages in there (which should be possible because we show a 'view' of mobile pages in the normal login), I think it wouldn't shrink to fit the screen, so everything would be tiny. Portal logins don't do all the specialized mobile things that the mobile login screen does. In other words, I don't think it would give you the results you desire.
There's nothing stopping you from making portals for employees - but I suggest using non-mobile optimzed screens if you do so that it fits the purpose of the portal login. What you are looking for is a 4th option ("Mobile Portal Login"), and that isn't on our roadmap right now. We definitely need to do a better job on that error message and give you a heads-up of why the screen isn't working. I'll put a ticket into the developers for that, and while they are we'll look into what it would take to make mobile screens viewable in portals, and the viability and possible timeline for making that happen.
But I need to ask, why use a portal instead of letting users be users and log in on the mobile login? There are mobile field service screens already designed to show schedules, track start and stop time per users, all based on the Method user that signs in - it's all done for you, so customization would be a lot easier to extend.
Paul