I'm guessing your portal would be like ours. A portal has some number of lanes (usually 1), and the routing system automatically routes near the portal, waits for a lane to become free, marks the lane as in use, then travels across it. Only certain units can travel across particular lane types. There is an animation that plays (very similar to the basic walking cycle) when a unit travels between the portal endpoints. And finally, you can place multiple portals together end-to-end and have them work continuously.
We have many kinds of portals. They include bridges, ramps, stairs, doors, and elevators.
For us, we simply add a portal component to a game object, fill in a few functions that the interface requires such as the portal type and the animation names, and routing automatically picks up whatever new portal type we added.
that sounds like a good way. but the thing is i added access logic to each building so they can tell the pathfinder in which various ways they can be traveled through. for example there maybe a tower with one door on ground level and two doors at the top leading outside where a wall can be. So the tower needs to tell pathfinder the ground door can be used if there's ground and not water for example or some other obstacle and the top doors can be used if there's some connection like walls/platform next to the doors.
this seems to require rather complex set of portals. so i might use some kind of portal component system or try to do better OO design.