Method Community

Method,

I just created a new portal, following this link: http://www.methodintegration.com/method/kb.aspx?folder=methodcrm&article=Setup-your-Portal&id=81

When logging in,  I am presented with:

I have tried all of the recommended actions and still the same error persists. There is no further indication of what the problem actually is. (Would be nice to  see the same Method error screen that is shown when there is an error within Actions.)

Assistance is greatly appreciated.

Thank you.

@vdefabis -

I'm guessing you are creating a customized portal rather than using the standard one?

Every portal has a default tab. If you view this tab regularly in Method, does this screen show up okay?

Also, can you verify that the screen is a normal screen, and not a mobile-optimized screen?

Paul

Screen shows up ok while "Viewing".

It is supposed to be a mobile-optimized page. (The portal is for my field techs to view their work orders.)

I unchecked optimize for mobile and it started working, but now that I've re-checked optimize for mobile to confirm that was the problem, I still see the non-optimized version of the page.

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

Paul - Thanks for the outline of how that works.

I'm a little disappointed that what I'm trying to do isn't supported. It doesn't seem very "out of the ordinary".

The problem with just letting users login is that the majority of my technicians are contractors who might use the platform only a couple of times per week.  I can't justify the $40/month charge for such little usage. Additionally, I have over 50 contractors - So even with the shared licensing, that is still roughly $800/month, which is cost prohibitive. I might only need 3-5 consecutively logged in accounts at one time and your current pricing structure does not allow for that.

I guess I will just have to build something more suitable off the Method API, but that was not something I really wanted to do at this time.

Thanks.

I understand.

Before you start coding, two things I should mention:

(1) I have a ticket in. So you might want to wait until I at least get an answer back on viability. We're not holding out on mobile screens in portals to make a quick buck off your contractors...it's just a design/resource/priority thing for us. So I can at least hear back and give you insight into what I hear.

(2) Try publishing a VERY simple non-mobile screen for the portal (like 1 column and two rows) and viewing it on a phone.  Does that look okay? If so, you might be able to design what you need. Best to try out and verify my hunch - I've never tried it, I'm just making an educated guess. My hunch could be wrong.

Paul

I can verify that building simple non-mobile screens will work.  I've done this for iPad and iPhone.

The trick is to limit data to 1 section per screen with multiple sections spread across tab links.  

Where formated data is needed we simply use a custom report.

@vdefabis - I heard back from the developers.  Good news, the actual act of looking into feasibility of doing it, led to 1/2 the work being done. So they got the go ahead to finish the other half.

The "September" version will have this 'fix', later this month. However, it should be noted that it still isn't a fully supported solution, in as much as it will show up in the portal the same way as it shows up inside regular non-mobile Method.This means you need to be very careful about applying your own security and filtering, and there won't be much available in terms of tweaks and improvements since only the mobile login is the intended destination for mobile-optimzed pages.

Paul